HTTPS & SSL

1. HTTPS

1.1. HTTPS가 나온 배경

• HTTP는 단순 텍스트를 교환하므로, 누군가 네트워크에서 신호를 가로채면 내용이 노출되는 보안 이슈가 존재한다.
• 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
• 이런 HTTP 보안 이슈를 해결해주는 프로토콜이 'HTTPS'이다. HTTPS는 HTTP 메세지(텍스트)를 암호화한다.

1.2. HTTPS

그림 2-61.SSL/TLS를 이용한 인터셉터 방지, 출처: 면접을 위한 CS 전공지식 노트

• HTTPS에서 S는 Over Secure Socket Layer을 뜻한다. HTTPS란 인터넷 상에서 정보를 암호화하는 SSL/TLS프로토콜을 이용해 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약이다. 
• HTTP 통신하는 소켓 부분을 인터넷 상에서 정보를 암호화하는 SSL(Secure Socket Layer)라는 프로토콜로 대체한 것이다. => SSL은 TCP api와 유사한 소켓이 있는 간단한 api를 제공한다

2. SSL

• 그렇다면 이런 것들이 가능하게 하는 SSL/TLS란 무엇일까?
  • SSL(Secure Socket Layer)은 SSL 1.0부터 시작해서 SSL2.0, SSL 3.0, TLS(Transport Layer Security Protocol)1.0, TLS 1.3까지 버전이 올라가며 마지막으로 TLS로 명칭이 변경되었으나, 보통 이를 합쳐 SSL/TLS라고 한다. 하지만 TLS라는 이름보다 SSL이라는 이름이 훨씬 많이 사용되고 있다. 
  • OSI 7계층에서 Presentation 계층에 속하며 보안을 제공하는 프로토콜이다.
  • HTTP에서 HTTP는 TCP와 통신했지만, HTTPS에서 HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다. 즉, 하나의 레이어를 더 둔 것이다.
    • 애플리케이션 계층의 프로토콜들은 외부로 보내는 데이터를 TCP가 아닌 SSL에 보내고, SSL은 받은 데이터를 암호화하여 TCP에게 보낸다. 또한 TCP로부터 받은 데이터를 복호화하여 애플리케이션 계층에 전달하게 된다. 그래서 Application과 TCP는 자신들의 사이에 SSL이 있다는 사실을 모른 상태로 통신이 가능하다. 즉, Application과 TCP는 SSL이 없는 것처럼 기존 전달 방식을 그대로 사용할 수 있다.
  • HTTPS의 SSL에서는 대칭키 암호화 방식과 공개키 암호화 방식을 모두 사용한다.
  • 클라이언트와 서버가 통신을 할 때 SSL/TLS를 통해 제 3자가 메세지를 도청하거나 변조하지 못하도록 한다.
  • 위 그림처럼 SSL/TLS를 통해 공격자가 서버인 척하며 사용자 정보를 가로채는 네트워크상의 '인터셉터'를 방지할 수 있다.

2.1. 대칭키 VS 비대칭키(공개키)

암호화 알고리즘에는 무엇이 있을까? 

대표적으로 대칭키 암호화 방식과 비대칭키 암호화 방식이 있다. 이 두 방식을 혼합한 하이브리드 방식이 SSL 암호화 방식이다.

2.1.1. 대칭키 암호화 방식(비밀키 암호화 방식)

• 하나의 대칭키(비밀키)를 이용한 암호화 방식
• 동일한 키를 주고받기 때문에, 속도가 빠르다는 장점이 있다.
• 하지만 키를 교환해야 하기 때문에 대칭키 전달과정에서 해킹 위험에 노출되기 쉽다.

2.1.2. 비대칭키 암호화 방식(공개키 암호화 방식)

• 공개키와 개인키를 이용한 암호화 방식
  • 공개키는 모든 사람이 접근 가능한 키이다.
  • 개인키는 각 사용자만이 가지고 있는 키이다.
• 대칭키의 키교환 문제를 해결하기 위해 등장했다.
• 예를 들어 A가 B에게 데이터를 보낸다고 할 때, A는 B의 공개키로 암호화된 데이터를 보내고 B는 본인의 개인키로 해당 암호화된 데이터를 복호화해서 보기 때문에 암호화된 데이터는 B의 공개키에 대응되는 개인키를 갖고 있는 B만이 볼 수 있다.

2.1.3. 대칭키와 비대칭키 방식을 혼합한 하이브리드 방식

SSL 통신 과정에서 사용되는 암호화 방식이다. HandShake 과정에서 신뢰성 확보 후 서로 대칭키를 생성한다.

1. A가 B의 공개키로 암호화 통신에 사용할 대칭키를 암호화하고 B에게 보낸다.(비대칭키 암호화 방식)
2. B는 암호문을 받고, 자신의 비밀키로 복호화한다.(비대칭키 암호화 방식)
3. B는 A로부터 얻은 대칭키로 A에게 보낼 평문을 암호화하여 A에게 보낸다.(대칭키 암호화 방식)
4. A는 자신의 대칭키로 암호문을 복호화한다.(대칭키 암호화 방식)
5. 앞으로 이 대칭키로 암호화를 통신한다.(대칭키 암호화 방식)
즉, 대칭키를 주고받을 때만 비대칭키 암호화 방식을 사용하고 이후에는 계속 대칭키 암호화 방식으로 통신하는 것이다.

2.2. SSL/TLS HandShake

HTTPS 통신 과정에서 SSL/TLS는 SSL/TLS HandShake를 통해 보안 세션을 생성하고 송신자와 수신자가 암호화 통신을 하기 위한 방법과 수단에 대해 공유해야 한다. 즉, 암호화된 데이터를 교환하기 전 이 과정(SSL/TLS HandShake)에서 SSL 인증서 전달, 키(대칭키, 비밀키 등) 전달, 암호화 알고리즘 결정(보통 SSL은 하이브리드 방식 사용), SSL/TLS 프로토콜 결정 등을 한다.

* 용어 정리

* 세션: 운영체제가 어떠한 사용자로부터 자신의 자산 이용을 허락하는 일정한 기간을 뜻한다. 즉, 사용자는 일정 시간동안 응용 프로그램, 자원 등을 사용할 수 있다.

* 보안 세션: 보안이 시작되고 끝나는 동안 유지되는 세션을 말하고, SSL/TLS는 핸드셰이크를 통해 보안 세션을 생성하고 이를 기반으로 상태 정보 등을 공유한다.

HTTP/TLS HandShake는 한 마디로 말하면 HTTPS에서 송신자와 수신자가 암호화된 데이터를 교환하기 전 SSL 인증서로 신뢰성 여부를 판단하기 위해 연결하는 방식이라고 할 수 있다.

TLS/SSL HandShake, 출처: gyoogle, 2021.10.30, https://github.com/gyoogle/tech-interview-for-developer/blob/master/Computer%20Science/Network/TLS%20HandShake.md

2.2.1. 진행 순서

1. 클라이언트 컴퓨터가 자신의 버전, 암호화 알고리즘 목록, 그리고 사용 가능한 압축 방식을 "client hello" 메시지에 담아 서버로 보낸다. 이 때 클라이언트측에서 생성한 랜덤 데이터를 같이 보낸다.
2. 서버는 클라이언트가 보낸 암호 알고리즘과 압축 방식을 받고, 클라이언트가 제공한 목록에서 서버가 선택한 암호 알고리즘, 선택한 압축 방식과 세션 ID 및 CA(Certificate Authority)가 사인한 서버의 공개 인증서(CA 인증서)를 "server hello" 메시지에 담아 응답한다. CA 인증서는 암호화에 사용할 서버의 공개키를 포함한다. 또한 서버측에서 생성한 랜덤 데이터도 같이 보낸다.
3. 클라이언트는 서버에서 보낸 CA 인증서에 대해 유효한 지 CA 목록에서 확인하는 과정을 진행한다. 이 과정을 통해 클라이언트가 접속한 '서버가 신뢰'할 수 있는 서버임을 알 수 있다.
4. CA 인증서에 대한 신뢰성이 확보되었다면, 클라이언트는 서버의 랜덤 데이터와 클라이언트가 생성한 랜덤 데이터를 조합해서 pre master secret라는 키를 생성해 서버의 공개키로 암호화한다. 
5. 만약 SSL / TLS 서버가 2번 단계에서 "클라이언트 인증서 요청"을 보낸 경우 클라이언트는 클라이언트의 디지털 인증서 또는 "디지털 인증서 없음 경고"를 pre master secret key와 함께 보낸다. 이 경고는 경고일 뿐이지만 일부 구현에서 클라이언트 인증이 필수일 경우 handshake를 실패한다.
6. 서버는 클라이언트의 인증서를 확인한다. 서버는 클라이언트가 전송한 pre master secret 값을 자신의 개인키(비공개키)로 복호화한다. 이로서 서버와 클라이언트가 모두 pre master secret 값을 공유하게 되었다. 그리고 서버와 클라이언트는 모두 일련의 과정을 거쳐서 pre master secret 값을 master secret 값으로 만든다. master secret는 session key를 생성한다. (후에 이 session key 값을 이용해서 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화 한 후에 주고 받는다.)
7. 클라이언트는 handshake의 클라이언트 부분이 완료되었음을 알리는 Finished 메시지를 서버에 보내면서 메세지에 지금까지의 교환 내역을 해시한 값을 대칭키로 암호화하여 담는다.
8. 서버도 동일하게 교환 내역들을 해싱한 뒤 클라이언트에서 보내준 값과 일치하는 지 확인한다. 일치하면 서버도 마찬가지로 대칭키를 통해 암호화한 Finished 메시지를 클라이언트에게 보낸다.
9. 클라이언트는 해당 메시지를 대칭키로 복호화하여 서로 통신이 가능한 신뢰받은 사용자란 걸 인지하고, 앞으로 클라이언트와 서버는 해당 대칭키로 데이터를 주고받을 수 있게 된다.

* 용어 정리

* CA(Certificate Authority): CA는 공개키 저장소이다. 신뢰성이 엄격하게 공인된 기업들만 참여할 수 있다. 대표적인 기업으로는 Comodo, 아마존 등이 있다.

2.3. HTTPS 통신 과정

1. 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다. 신뢰할 수 있는 CA 기업을 선택하고, 그 기업에게 내 공개키 관리를 부탁하며 계약을 한다.
2. 계약을 완료한 CA 기업은 CA 기업만의 공개키와 개인키가 있다. CA 기업은 CA기업의 이름과 A서버의 공개키, 공개키의 암호화 방법 등의 정보를 담은 인증서를 만든다.
3. 해당 인증서를 CA 기업의 개인키로 암호화해서 A서버에게 발급한다.
4. 브라우저(클라이언트)의 소스코드 안에 CA의 리스트가 들어있다. 브라우저가 미리 파악하고 있는 CA의 리스트에 포함되어야만 공인된 CA가 될 수 있다.
5. 클라이언트가 A서버에 접속 요청을 한다.
6. A서버는 "A서버의 공개키로 암호화된 HTTPS 요청이 아닌" 요청(Request)가 오면, 이 암호화된 인증서를 클라이언트에게 준다. => 위에서 말한 SSL HandShake 과정 시작
   • 클라이언트가 main.html 파일을 달라고 A서버에 요청했다고 가정하자. HTTPS 요청이 아니기 때문에 클라이언트는 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게 된다.
7. CA 기업의 공개키는 클라이언트가 이미 알고있다.(4번) 클라이언트는 CA 기업의 공개키로 인증서를 검증할 수 있다.
   • CA의 공개키를 이용해서 인증서를 복호화 할 수 있다는 것은 이 인증서가 CA의 개인키(비공개키)에 의해서 암호화 된 것을 의미한다. 해당 CA의 개인키를 가지고 있는 CA는 해당 CA 밖에 없기 때문에 서버가 제공한 인증서가 CA에 의해서 발급된 것이라는 것을 의미하는 것이다.
8. 클라이언트(브라우저)는 인증서를 해독한 뒤 A서버의 공개키를 얻게 되었다.
9. A 서버의 공개키로 대칭키(정확히는 pre master secret값)를 암호화하여 전송한다.
10. A서버는 공개키로 암호화된 대칭키를 A서버의 개인키로 복호화하여 대칭키를 획득한다. => SSL HandShake 과정 종료
11. 이 후로 대칭키로 암호화된 데이터를 주고받는다.

HTTPS는 항상 안전할까?

• HTTPS도 무조건 안전한 것은 아니다.
  • 신뢰받는 CA 기업이 아닌 자체적으로 인증서 발급한 경우
  • 신뢰할 수 없는 CA 기업을 통해서 인증서를 발급받은 경우
• 이때는 HTTPS지만 브라우저에서 주의 요함, 안전하지 않은 사이트와 같은 알림으로 주의 받게 된다.

 

---

참고

https://github.com/gyoogle/tech-interview-for-developer/blob/master/Computer%20Science/Network/TLS%20HandShake.md

GitHub - gyoogle/tech-interview-for-developer: 👶🏻 신입 개발자 전공 지식 & 기술 면접 백과사전 📖

https://opentutorials.org/course/228/4894

HTTPS와 SSL 인증서 - 생활코딩

https://github.com/WooVictory/Ready-For-Tech-Interview/blob/master/Network/HTTP%2C%20HTTPS.md

GitHub - WooVictory/Ready-For-Tech-Interview: 💻 신입 개발자로서 준비를 하기 위해 지식을 정리하는 공간

 

https://liveyourit.tistory.com/183

[암호학] 대칭키 vs 공개키(비대칭키) 암호화 차이

https://wangin9.tistory.com/entry/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EC%97%90-URL-%EC%9E%85%EB%A0%A5-%ED%9B%84-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EC%9D%BC%EB%93%A4-5TLSSSL-Handshake

[브라우저에 URL 입력 후 일어나는 일들] 5_TLS/SSL Handshake

https://aws-hyoh.tistory.com/entry/HTTPS-%ED%86%B5%EC%8B%A0%EA%B3%BC%EC%A0%95-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-3SSL-Handshake

HTTPS 통신과정 쉽게 이해하기 #3(SSL Handshake, 협상)

https://jeong-pro.tistory.com/89

Http와 Https 이해와 차이점 그리고 오해(?)

https://12bme.tistory.com/80

[정보보안] SSL(Secure Socket Layer) 이란