HTTPS에서 S란?

신창호·2022년 7월 22일
0
post-thumbnail

HTTPS

  • HTTPS는 여러 이름이 있는데 아래와 같다.
    • HTTPS(HyperText Transfer Protocol over Secure Socket Layer)
    • HTTP over TLS
    • HTTP over SSL
    • HTTP Secure
  • 쉽게말해, 기존 HTTP에서 보안이 추가되어 HTTPS가 되었다고 생각하면 된다.
  • 그래서 현재는 대부분의 URI가 https:// 로 시작된다.



보안

암호화

  • HTTP를 사용하는 웹사이트에 접속했다면 ⚠️Not Secure라는 메시지가 뜰 것이다.
  • HTTP 통신은 데이터를 있는 그데로 요청하고 응답하기 때문에, 중간에서 탈취당하게되면, 있는 그대로의 정보를 노출되는 것이다.
    • 만약, 통신한 정보가 개인정보같이 중요한 정보라면 위험한 일이다.
  • 그래서 HTTPS는 SSL 혹은 TLS라는 알고리즘을 이용해 데이터를 암호화하여 전송한다.

인증서

  • HTTPS의 또 다른 특징은 브라우저가 서버의 응답과 함께 응증서를 확인할 수 있다는 점이다!
    • 아래 사진처럼 클릭하여 들어가면 인증서를 볼 수 있다.

CA(Certificate Authority)

  • 이 인증서를 보증해주는 제 3자를 CA라고 부른다. (뜻도 인증기관이다.)
  • CA는 인증서를 발급해주는 엄격하게 공인된 기관으로, 만약 URL은 HTTPS이지만 CA 기관이 아닌 곳에 접근하여도 신뢰성없는 페이지라며 주의 메시지가 뜬다.
  • 인증서를 발급받으려면 인증 서명 요청서를 CA에 만들어서 신청해야된다.
    • 요청서에 들어갈 정보로는 국가코드, 도시, 회사명, 부서명, 이메일, 도메인 주소, 사용하게될 공개키
    • 즉, CSR은 '내가 어느 도시에 있는 어떤 회사인데 이 키(공개키)를 가지고 인증서를 발급받고 싶다'라고 인증기관에게 인증서를 요청하는 신청서.
  • 인증서에 유효기한도 있어, 기한이 다하면 갱신해줘야한다.
  • 여담으로, 인증되지않은 사이트의 경우 검색엔진에서도 잘 노출되지 않는다고한다.(애초에,찾기도 힘듬)

그럼 대체 어떻게 암호화를 하는 것일까? 그리고 TLS, SSL은 무엇일까?






SSL/TLS

  • 위에서 HTTPS를 풀어쓴 내용중에 HTTP over TLS, HTTP over SSL이 보일 것이다.
  • 이것은 HTTPS의 인증서를 받기위한 암호화 방식이라고 할 수 있다.
  • SSL/TLS를 들어가기전에, 대칭키비대칭키에 대해 알아야 한다.

대칭키

  • 암호를 만드는 행위를 할 때 사용하는 일종의 비밀번호를 키(key)라고 한다.
    • 이 키에 따라서 암호화된 결과가 달라지기 때문에 키를 모르면 암호를 푸는 행위인 복호화를 할 수가 없다.
  • 대칭키는 동일한 키로 암호화와 복호화를 같이 할 수 있는 방식의 암호화 기법을 의미한다.

  • 즉, 암호화를 할 때 abc라는 값을 사용했다면, 복호화를 할 때 도 abc라는 값을 입력해줘야 된다.

비대칭키

하지만 대칭키 방식은 단점이 있다. 바로 암호화하고 복호화할 때 필요한 키(key)가 노출이되면, 외부인(공격자)이 암호의 내용을 복호화하여 볼 수 있기 때문이다.
이러한 문제를 해결하기 위해 나온 것이 비대칭키 방식이다.

  • 비대칭키 방식은 두개의 키를 갖게된다.
    • A키를 암호화를 하면 B키로 복호화할 수 있고, B키로 암호화하면 A키로 복호화할 수 있는 방식
    • 두 키중 하나는 개인키(private)로 하고, 나머지 하나는 공개키(public)로 지정한다.
  • 공개키 만드는 방식으로는 PKCS12을 많이 쓴다.

암호화 복호화 과정

  • 그래서 결국 공개키를 제공받은 클라이언트는 정보를 (공개키로)암호화한다.
  • 이 암호화된 정보를 개인키를 가지고 있는 서버에게 전송한다.
  • 개인키를 소유하고 있는 서버는 (개인키로)정보를 복호화하여 확인할 수 있다.

결국 공개키로는 암호화 할 수 있지만, 복호화는 할 수 없기 때문에, 외부에서 공개키를 알아도 정보를 복호화 할 수 없다.



SSL

  • SSL(Secure Sockets Layer, 보안 소켓 계층)
  • 서버와 클라이언트 사이에 교환되는 데이터를 암호화하여 보안을 유지하는 표준 기술
  • 당연히 해커가 전송되는 정보를 열람하거나 훔치는 것을 방지(스니핑, 스누핑 방지)
  • 개인키(private)와 공개키(public)의 대칭키 기반으로 암호화/복호화를 사용한다.(비대칭키와 대칭키의 혼합)
    • SSL 통신에 사용할 공개키를 클라이언트에게 제공한다.
    • 공개키로 암호화된 데이터는 개인키로만 복화화 할 수 있다.
  • SSL 3.0 이후 지원이 중단되었음.

TLS

  • 1999년에 SSL 3.0의 업그레이드 버전으로 TLS 1.0이 공개되었다.(SSL의 업그레이드 버전)
  • 이후 SSL에서 TLS로 명칭이 변경되었으나, SSL이라는 명칭이 아직까지 보편적으로 사용되고 있어서 TLS/SSL을 혼용하여 사용한다.
  • 즉, SSL이랑 TLS는 같은 말이다

인증절차

  1. 사용자가 브라우저를 통해 서버에 접속하면, 서버에서 인증서를 사용자에게 제공.
  2. 브라우저는 인증서를 발급한 인증기관이 브라우저에서 제공하는 인증기관 목록에 있는지 확인.(브라우저가 CA목록을 알고 있음)
  3. 인증기관의 공개키를 이용해서 인증서를 복호화.
  4. 복호화에 성공하는 것으로 인증완료.

네트워크를 통한 데이터 통신에 쓰이는 프로토콜인 TLS와 SSL의 오픈 소스 라이브러리 OpenSSL 이 있다.

동작방법

위에서 SSL은 비대킹키와 대칭키를 혼합해서 사용한다고 했다. 좀더 자세히 알아보자

  • 클라이언트와 서버가 주고 받는 실제 정보는 대칭키 방식으로 암호화하고
  • 이 대칭키를 공개키 방식으로 암호하 하여, 클라이언트와 서버가 정보를 주고 받게 된다.
  • 이렇게 하는 이유는 정보를 비대칭키 방식으로 암호화하여 통신하게되면 매우 많은 컴퓨터 자원을 사용하기 때문이다.

1. 클라이언트가 서버에 접속한다. 이 단계를 Client Hello라고 한다.

  • 주고 받는 정보
    • 클라이언트 측에서 생성한 랜덤 데이터
    • 클라이언트가 지원하는 암호화 방식들
      • 클라이언트와 서버가 지원하는 암호화 방식이 서로 다를 수 있기 때문에 상호간에 어떤 암호화 방식을 사용할 것인지에 대한 협상을 해야 합니다. 이 협상을 위해서 클라이언트 측에서는 자신이 사용할 수 있는 암호화 방식을 전송하게 됩니다.
    • 세션 아이디(이미 SSL 핸드쉐이킹한 경우)
      • 세션 아이디를 발급받은 경우, 사용할 연결에 대한 식별자를 전송

2. 서버는 Client Hello에 대한 응답으로 Server Hello를 한다.

  • 주고받는 정보
    • 서버 측에서 생성한 랜덤 데이터
    • 서버가 선택한 클라이언트의 암호화 방식
      • 클라이언트가 전달한 암호화 방식 중에서 서버 쪽에서도 사용할 수 있는 암호화 방식을 선택해서 클라이언트로 전달한다.
      • 이로써 암호화 방식에 대한 협상이 종료되고 서버와 클라이언트는 이 암호화 방식을 이용해서 정보를 교환하게 됩니다.
    • 인증서(서버의 공개키도 포함되어 있다.)

3. 클라이언트는 서버의 인증서가 맞는지 확인한다.

  • HTTPS에 맞는 서버라면 CA에 의해서 발급된 인증서일텐데,
  • 클라이언트는 내장된 CA리스트(이때 공개키도 같이 있다.)를 확인하다.
    • 만약 CA리스트에 인증서가 없다면, 사용자에게 경고 메시지를 출력
  • 리스트에 있다면, 인증서가 CA에 의해서 발급된 것인지 확인한다.
    • CA의 공개키를 이용해서 인증서를 복호화하며, 복호화 성공시 인증서는 CA의 개인키로 암호화된 문서임이 보장된다.
  • 이로써, 인증서를 전송한 서버를 신뢰할 수 있게 된다.

이렇게 신뢰할 수 있는 서버라는 것이 확인이 되면 다음으로는 세션을 위한 준비를 한다.

4.pre master secret값을 서버에게 보낸다.

  • 서버의 랜덤 데이터와 클라이언트가 생성한 랜덤 데이터를 조합해서 pre master secret이라는 키를 생성하게 된다.
  • 이 키값은 세션을 만들기위해서 서버로 보내줘야하는데,
  • 이때 서버의 공개키로 pre master secret 값을 암호화해서 서버로 전송한다.

5. 서버는 pre master secret 값을 자신의 비공개키로 복호화합니다

  • 이로써, 서버와 클라이언트 모두 pre master secret값을 공유하게 된다.
  • 이제 이 키값은 master secret 값으로 만들고, master secret은 session Key를 생성한다.
    • 이젠 session key 값을 이용해서 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화한 후에 주고 받을 수 있게 된다.

6. 클라이언트와 서버는 핸드쉐이크 단계의 종료를 서로에게 알린다.

7. 서로 메시지 교환을 한다.

8. 데이터 전송이 끝나면

  • TLS 통신이 끝났음을 서로에게 알리고,
  • 통신에서 사용한 대칭키인 세션키를 폐기한다.






TLS 인증서 발급

CA 기관

  • 클라이언트 웹 브라우저에 이미 리스트업(CA리스트)되어 있는 인증서를 발급해주는 유명한 CA기관들이 있다.
  • 금융결제원(KFTC)
    • 우리나라 금융산업의 핵심 인프라인 지급결제시스템을 구축 운영함으로써 사원은행 및 이용고객에게 다양하고 편리한 지급결제서비스를 제공하는 전문기관
    • 2008년 2월부터 Yessign 공인인증센터를 설립하여 운영함으로써, 국산 SSL 웹서버인증서 및 CodeSign 인증서를 발급하고 있으며,
    • 2010년 부터 WildCard 및 Global인증서를 함께 판매하고 있다.

참고링크

profile
한단계씩 올라가는 개발자

0개의 댓글