HTTPS(SSL/TLS) 세션 성립 과정

당연히 TCP의 3way handshaking이 선행되고, 그 이후의 과정을 다룬다.

암호화 통신을 하기위해서는 여러가지 과정이 존재하는데, 클라이언트와 서버가 HTTPS 세션을 성립시키는 과정을 이해하려면 먼저 서버가 인증서를 어떻게 만드는지를 이해해야 한다.

최초로 서버는 자신이 클라이언트에게 보내는 인증서가 ‘클라이언트로부터 신뢰받은 인증서’로 취급받기 위해, 신뢰되는 CA기관에 본인이 만든 인증서를 위탁하며 CA 기관에서 해당 인증서의 서명을 부탁한다.
그럼 CA기관은 전달받은 인증서의 여러가지 값들(TBSCertificate에 사용하는 값)을 한데모아 해시 값을 만들고, 만든 해시값을 CA기관의 ‘비대칭키 암호화 알고리즘의 개인키’를 사용해 암호화하여 인증서에 기재한다.

이는 인증서의 신원보증과 무결성검증을 함으로써 클라이언트로부터 신뢰받은 인증서로 취급받기 위함인데, 이렇게 하는게 신원보증/무결성검증과 무슨 상관인지는 나중에 클라이언트와 서버의 세션 성립 과정에 대해 설명하면서 언급하겠다.

서버의 인증서에 CA기관 인증 딱지(이하 CA딱지)를 붙인 뒤 CA 기관은 다시 CA딱지가 붙은 인증서를 서버에 반환한다. 그리고 서버는 CA딱지가 붙은 인증서를 클라이언트들에게 나눠주기 위해 보관한다.

 

다음은 실제 클라이언트와 서버가 HTTPS 통신 시 어떻게 인증서를 검증하고, 암호화통신을 수행하는지 알아보겠다.

1. 제일 먼저, 클라이언트가 서버에 HTTPS 연결을 요청한다.(Client Hello)

2. 그러면 서버는 CA딱지가 붙은 인증서를 클라이언트에게 전송한다.(Server Hello, Certificate)

3. 클라이언트는 수신된 인증서가 신뢰할 만한지, 본인의 신뢰하는 인증기관 목록 중에 서버 인증서의 발급기관 존재 유뮤를 확인한다.(Certificate)

[만약 신뢰하는 인증기관 목록에 포함되지 않는다면?]

이때 만약 수신된 서버의 인증서가, 신뢰하는 인증 기관 목록의 CA기관에서 발급한게 아니라면, 신뢰하지 않는 연결로 간주해 브라우저는 경고메시지를 띄운다.

 

4. 인증서의 발급기관이 신뢰하는 인증기관으로 존재한다면, 클라이언트가 보유한 인증기관의 공개키를 사용해 암호화된 해시 값(CA 기관의 서명)을 복호화하여 원본 해시 값(TBSCertificate 해시 값)을 획득한다. 클라이언트가 보유한 인증기관의 공개키를 사용해 해시 값 복호화에 성공했다면, 이는 곧 CA기관에서 개인키로 해시 값을 암호화했다고, 이 인증서가 CA 기관에서 발급한게 맞다고 증명하는, 신원보증이 되는셈이다. 

 > [신원보증? 왜 필요한데?]

이 신원보증 그리고 무결성검증하는 단계를 Certificate라고 하는데, 이 Certificate 패킷은 아직 HTTPS 세션이 맺어지기 전이라 평문으로 확인할 수 있고, 이는 곧 해커가 중간에 Certificate 패킷을 발견하곤 본인의 인증서로 바꿔치기가 가능함을 뜻한다. 그래서 해커가 발급한 임의의 인증서는 CA딱지가 없는, 신뢰할 수 없는 인증서일것이니, CA 딱지를 통해 해당 인증서가 어디서 발급됐는지 확인해 인증서의 신뢰유무를 체크하는 것이다. 잠깐, 그럼 해커가 CA딱지가 있는 본인의 인증서로 바꿔치기 한다면? > 그래서 무결성검증이 추가로 필요하다.

 

5. 이후, 복호화된 해시 값과 인증서의 값들로 신규 해시 값을 생성해 서로 비교하여 실제 CA 기관에서 사인 한 값과 인증서의 내용이 동일한지 비교한다. 여기서 인증서의 무결성 검증이 이루어진다.

 > [무결성 검증? 왜 필요한데?]

신원보증을 통과하더라도, A 서버의 인증서를 서명해줬던 서명 값을 B 서버의 인증서에 넣었을때 역시 신원보증을 통과할 수 있으니 결국 신원보증만으로는 해당 인증서의 변조유무를 알 수 없다. 그래서 실제 CA기관에서 서명한 인증서가 지금 이 인증서가 맞는지 확인하는 작업이 필요하다.

 

6. 비교해 서로 동일한 값이라면 무결성 검증이 이루어졌다 판단, 클라이언트는 서버에게 받은 정보들을 사용해 대칭키 암호화 알고리즘 기반의 대칭키를 생성한다.(Client Key Exchange)

7. 생성한 뒤 서버로부터 전달 받았던 인증서에서 서버의 공개키를 추출해 서버의 공개키로, 대칭키를 암호화하여 서버로 전송한다.(Client Key Exchange)

8. 서버는 "본인의 공개키로 암호화 된 클라이언트의 대칭키"를 본인의 개인키로 복호화하여 클라이언트가 전송한 대칭키를 확인한다.(Change Cipher Spec/Finished)

9. 이후 해당 키를 사용하여 서로 암호화 통신을 수행한다.

 

자세한 과정 여러개가 생략됐지만 사실 이렇게만 이해해도 HTTPS 통신과정의 큰틀을 이해한다 할 수 있겠다.
이를 기반으로 HSTS, SSL Strip, HPKP, Insecure Client-Initiated Renegotiation 등 SSL 관련 지식을 익히는데에는 무리 없을거다.

 

단, TLS 1.3부터는 암호키 교환 매커니즘이 살짝 바뀌는데 궁금하다면 본 블로그 포스팅 TLS1.3을 참고하자