TLS/SSL HandShake
- HTTPS에서 클라이언트(웹사이트)와 서버간 통신 전
SSL 인증서로신뢰성 여부를 판단하기 위해 연결하는 방식
진행 순서
- 클라이언트는 서버에게
client hello 메시지를 담아 서버로 보낸다. 이때암호화된 정보를 함께 담는데, 버전, 암호 알고리즘, 압축 방식 등을 담는다. (C --"client hello" + 암호화된 정보--> S)
- 서버는 클라이언트가 보낸 암호 알고리즘과 압축 방식을 받고,
세션 ID와 CA 공개 인증서를 server hello 메시지와 함께 담아 응답한다. 이 CA 인증서에는 앞으로 통신 이후 사용할 대칭키가 생성되기 전, 클라이언트에서 handshake 과정 속 암호화에 사용할공개키를 담고 있다. (S --"server hello" + 세션ID, CA공개 인증서-->C)
- 클라이언트 측은 서버에서 보낸
CA 인증서에 대해 유효한 지 CA 목록에서 확인하는 과정을 진행한다. (C : CA 인증서 유효성 확인)
CA 인증서에 대한 신뢰성이 확보되었다면, 클라이언트는난수 바이트를 생성하여서버의 공개키로 암호화한다. 이 난수 바이트는대칭키를 정하는데 사용이 되고, 앞으로 서로 메시지를 통신할 때암호화하는데 사용된다. (C --난수 바이트 생성해서 서버의 공개키로 암호화--> S)
- 만약 2번 단계에서 서버가 클라이언트 인증서를 함께 요구했다면, 클라이언트의 인증서와 클라이언트의 개인키로 암호화된 임의의 바이트 문자열을 함께 보내준다.
- 서버는 클라이언트의 인증서를 확인 후,
난수 바이트를 자신의 개인키로 복호화 후 대칭 마스터 키 생성에 활용한다. (S:난수 바이트를 개인키로 복호화 -> 대칭 마스터키 생성에 활용)
- 클라이언트는 handshake 과정이 완료되었다는
finished 메시지를 서버에 보내면서, 지금까지 보낸교환 내역들을 해싱 후 그 값을 대칭키로 암호화하여 같이 담아 보내준다. (C --"finished" + 교환 내역을 해싱 후 대칭키로 암호화해서 전송 --> S)
- 서버도 동일하게
교환 내용들을 해싱한 뒤 클라이언트에서보내준 값과 일치하는 지 확인한다. 일치하면 서버도 마찬가지로finished 메시지를 이번에 만든대칭키로 암호화하여 보낸다. (S-- 대칭키로 암호화된 "finished" + 교환 내역을 해싱 후 값 일치 확인 --> C)
- 클라이언트는 해당 메시지를
대칭키로 복호화하여 서로 통신이 가능한신뢰받은 사용자란 걸 인지하고, 앞으로 클라이언트와 서버는해당 대칭키로 데이터를 주고받을 수 있게된다. (S : finished 메시지를 대칭키로 복호화 후 신뢰성 확인하고 해당 대칭키로 서버와 데이터 주고받을 수 있음)
[출처]
