HTTPS

공개키(비대칭키) vs 대칭키

대칭키란?

• 암복호화키가 동일한 암호화 방식으로써 해당 키를 아는 집단끼리만 문서를 복호화해서 볼 수 있음
• 암호화와 복호와에 쓰이는 키가 같기 때문에 연결된 클라이언트마다 키의 종류가 달라야 하기 때문에 연결된 클라이언트가 많아질 수록 키 관리에 어려움이 있다.
• 또한 키를 배송하는 방법이 어려움 -> 키 교환 방식에 공개키 방식 사용
• 속도는 공개키 방식보다 빠르다. -> SSL 통식에 사용

공개키란?

• 공개키와 개인키 2개의 키로 암복호화 하는 방식이다.
• 공개키로 암호화를 하면 개인키로 복호화 할 수 있고, 개인키로 암호화하면 공개키로 복호화 할 수 있다.
• 공개키를 알아도 개인키를 모르면 복호화 할 수 없기 때문에 안전하다.
• 따라서 양측 통신간에 데이터를 상대의 공개키를 통해 암호화해서 보낸 후, 상대가 자신의 공개키로 암호화한 데이터는 개인키로 복호화 하여 사용한다.
• 속도는 대칭키 방식보다 느리지만 키관리와 키 분배시 보안에 유리하다.
• SSL(TSL) handshake 과정에서 사용한다.
• 공개키를 통해 비밀키로 암호화한 데이터를 복호화 할 수 있다는 개념을 이용해서 전자 서명에활용한다.

공개키 통신 절차

1. 송신자는 수신자의 공개키를 구한다.
2. 송신자는 수신자의 공개키로 평문을 암호화한다.
3. 송신자는 암호화된 메시지를 상대방에게 전달한다. 메시지는 암호화 되어서 중간에 유출되거나 도청이 되더라도 암호문으로부터 원문을 알아내기 어렵다.
4. 수신자는 자신의 비밀키(개인키)로 암호화된 메시지를 해독해서 평문을 얻는다.

HTTPS란?

• 이름에서 알 수 있듯 HTTP 에서 SSL(Secure Socket Layer)를 거쳐 암호화된 월드 와이드 웹 통신 프로토콜이다.
  • HTTP -> SSL or TLS -> TCP -> IP -> Network Interface 같은 순서
• 최근에는 SSL의 최신 버전인 TLS(Transport Layer Security)이 쓰이지만 통상적으로 TLS 또한 SSL로 불린다. SSL이 1.0,2.0,3.0까지하고 TLS로 바뀌었는데 3.0을 개량한 버전이다. 여기서 이미 SSL이라는 용어가 너무 널리 퍼져서 TLS를 쓰고있지만 SSL로 불린다.
• HTTPS의 기본 포트는 443 (http는 80)
• SSL은 공개키, 대칭키 방식을 혼합하여 사용한다.
• RSA(Rivest, Shamir and Adleman), ElGamal, ECC(Elliptic Curve Cryptosystem, 타원 곡선 암호 시스템)방식등이 있다.

쓰는 이유

1. HTTP의 보안 문제가 있다. HTTP 통신으로 보내면 중간에 가로채서 정보가 노출될 수 있기 때문이다.TCP/IP는 도청 가능한 네트워크인데 이는 통신 구조상 패킷이 여러 경로를 거쳐서 전송된다.(스위치, 라우터) 따라서 암호화 되지 않은 패킷은 여러 도청이 가능하다.(Sniffing)
2. 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
   1. HTTP는 요청을 보내는 상대가 누구인지 확인하는 처리가 없다. 즉 누구든지 request 가능하다.
   2. request를 보낸 곳의 웹 서버가 의도한 response를 보내야 하는 웹서버인지 확인할 수 없다.
   3. 통신하고 있는 상대가 접근이 허가된 상대인지를 확인할 수 없다.
   4. 어디에서 누가 request 했는지 확인할 수 없다.
   5. 의미없는 requst도 수신한다. -> DoS 공격을 방지할 수 없다.
   6. 위 암호화 방법으로 언급된 SSL로 상대를 확인할 수 있다. SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있다. 증명서는 신뢰할 수 있는 제 3자 기관에 의해 발행되기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다.
3. 중간에 데이터가 변조돼도 확인할 수 없다.
   1. 리퀘스트나 리스폰스를 빼앗아 변조하는 공격인 중간자 공격(Man-in-the-Middle)을 파악할 수 없다. (중간자 공격에는 스니핑, 스푸핑이 있다. 스푸핑은 예를들어 두 대상의 MAC주소를 공격자 자신의 MAC주소로 바뀌어 중간에서 패킷을 가로채는 공격같이 패킷을 탈취하는 것이다. 스니핑은 중간에서 패킷을 엿듣는 것이다. 즉 네트워크를 도청하는 행위이다. 스누핑은 네트워크 상에 떠도는 중요 정보를 몰래 획득하는 행위이다. 스니핑과 비슷하지만 스니핑은 몰래 엿듣는 의미가 조금 더 강하다.)
   2. 반면 HTTPS는 암호화되어 있기 때문에 위변조가 불가능하다. 즉 탈취해도 복호화를 못한다.

SSL 인증서

https의 통신과정을 위해선 SSL 인증서를 알아야 한다. SSL 인증서는 대칭키 방식과 공개키 방식을 혼합한 방법을 사용한다고 했는데, 공개키 방식은 대칭키를 배송하는 역할에만 쓰인다. (SSL handshake) 공개키 방식은 대칭키 방식보다 속도가 월등히 느리기 때문에 공개키 방식을 통해 대칭키를 배송 후 데이터는 대칭키를 이용하여 암호화, 복호화를 한다. 이때 SSL인증서가 사용된다.

CA(Certificate authority)

• 인증서의 역할은 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지 보장하는 역할을 한다.
• 이 과정에서 증명해주는 민간기업들이 있는데 이런 기업을 CA라고 한다.
• SSL을 통해서 암호화된 통신을 제공하려는 서비스는 CA를 통해서 인증서를 구입해야한다.
• 브라우저는 CA의 공개키를 처음부터 가지고있다.(통신 없이 CA의 공개키를 알고 잇다.)

SSL 인증서의 내용

1. 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인 등)
2. 서버 측 공개키(공개키의 내용, 공개키의 암호화 방법)

SSL 인증서가 서비스를 보증하는 방법

1. 웹 브라우저가 서버에 접속할 때 서버는 제일 먼저 인증서를 제공한다.
2. 브라우저는 이 인증서를 발급한 CA가 내장된 CA리스트에 있는지 확인한다.
3. 있으면 해당 공개키를 이용하여 인증서를 복호화 한다.
4. 인증서를 복호화 할 수 있다면 인증서가 CA의 비공개키에 의해서 암호화 된 것을 의미한다.
5. 따라서 해당 서비스를 신뢰할 수 있다.

SSL 동작 방법

• SSL은 암호화된 데이터를 전송하기 위해서 속도가 빠른 대칭키 방식과 안전한 공개키 방식을 혼합하여 사용한다.
• 공개키 방식을 이용하여 대칭키를 교환한다.(SSL handshake)

1. Clinet Hello
   1. 브라우저는 서버가 HTTPS를 사용하는 것을 알게되면 Client Hello를 함
   2. 다음과 같은 정보가 포함된다.
      • 브라우저가 사용하는 SSL 혹은 TLS 버전 정보
      • 브라우저가 지원하는 암호화 방식 모음(cipher suite)
      • 브라우저가 순간적으로 생성한 임의의 난수(숫자)
      • 만약 이전에 SSL 핸드 셰이크가 완료된 상태라면, 그때 생성된 세션 아이디(Session Id)
      • 기타 확장 정보(extension)

• cipher suite 이란, 보안의 궁극적 목표를 달성하기 위해 사용하는 방식을 패키지의 형태로 묶어놓은 것을 의미한다.
  • 안전한 키 교환
  • 전달 대상 인증
  • 암호화 알고리즘
  • 메시지 무결성 확인 알고리즘

2. Server Hello

• 브라우저의 암호화 방식 정보 중에서, 서버가 지원하고 선택한 암호화 방식(cipher suite)
• 서버의 공개키가 담긴 SSL 인증서 (인증서는 CA의 비밀키로 암호화되어 발급된 상태)
• 서버가 순간적으로 생성한 임의의 난수(숫자)
• 클라이언트 인증서 요청(선택사항)

3. 클라이언트에서 서버 인증서 확인

• 서버에서 보낸 인증서는 CA의 개인키(비밀키)로 암호화 되어 있음
• 이 인증서를 CA의 공개키로 복호화 할 수 있다면 해당 서버는 CA로부터 인증받은 기관임을 증명

4. 클라이언트는 자신이 1번 과정에서 생성한 난수와 2번과정에서 서버가 생성한 난수를 사용하여 대칭키에 사용될 premaster secret 를 만든 후 서버로 보냄

• 서버로 보내는 과정에서 데이터는 서버의 공개키를 활용하여 암호화
• 서버의 공개키는 서버가 보낸 SSL 인증서에 포함되어 있음

5. 서버는 사이트의 비밀키로 클라이언트가 보낸 premaster secret 값을 복호화

• premaster secret을 복호화 한 값을 master secret 값으로 저장
• 이것을 이용해 session key(대칭키)를 생성
• 서버는 이 session key를 이용하여 클라이언트와 통신

6. 서버는 SSL 핸드셰이크가 종료됐음을 알림

그 외 HTTPS의 이점

SEO(search engine optimization) 이점

• SEO는 검색엔진 최적화로서 검색 엔진으로부터 웹사이트나 웹페이지에 대한 웹사이트 트래픽의 품질과 양을 개선하는 과정이다.
• 구글은 HTTPS 웹사이트에 가산점을 주기 때문에 HTTPS를 사용하는 웹사이트는 상위에 노출될 확률이 올라간다.
• 사용자들 또한 HTTPS의 안전성 때문에 더 많이 방문해서 SEO에 유리

AMP(Accelerated Mobile Pages) 가속화된 모바일 페이지 사용 가능

• AMP는 모바일 기기에서 훨씬 빠르게 콘텐츠를 로딩하기 위한 방법으로 구글이 만들었다.
• AMP는 HTTPS에서만 사용 가능하다.

HTTP vs HTTPS

• HTTPS와 HTTP는 보안과 속도의 tradeoff관계를 가진다.
• 그런데 https가 더 빠르고 좋다라는 의견도 있다.
  • https://tech.ssut.me/https-is-faster-than-http/
• 암호화 비용은 생각보다 크지않다.
• 그리고 통신속도에 비해 CPU와 메모리 성능은 월등히 발전했다.
• Keep-Alive와 session resumption(세션 재개)은 대부분의 요청이 핸드쉐이크 과정을 요구하지 않는다.
• 또한 HTTP/1.1 보다 빠른 HTTP/2는 HTTPS에서만 동작한다. (HTTP에서도 동작하긴 하는데, 크롬 파폭 등에선 못함)
• 이러한 이유들로 HTTPS는 속도도 HTTP보다 느리지 않다는 주장이 나왔다.