HTTPS 특강 정리

Interdouction

TLS protocol의 목적은 두 커뮤니케이션하는 애플리케이션의 privacy와 data integrity를 보장하는 것이다.

HTTP Over TLS

Connection Intiation

• HTTP Client Agent는 TLS Client로써 동작해야한다.

• TLS Client는 Server의 적절한 포트번호로 TLS ClientHello를 날려 TLS handshake를 시작한다.

• TLS handshake가 종료되면 HTTP Client (TLS Client)는 첫번째 HTTP 요청을 날린다.

• 모든 HTTP data는 MUST 하게 TLS “application data”로써 전송 되어야한다.

• 레코드 프로토콜
• data integrity
• 전송될 메시지의 형식을 결정 (압축, 파편화, 암호화)

• 핸드세이크 프로토콜
• privacy
• 키 교환 / 합의 프로토콜
• 목적 - 클라이언트와 서버간의 안전한 대칭키 공유

TLS handshake Protocol

1. 클 ClientHello
• 클라이언트에서 생성한 랜덤 데이터， 클라이언트가 지원하는 암호화 방식들 chipher suites， 세션 ID 등 포함한 패킷을 서버로 전송
• “인증서(서버가 만든 공개키 에 CA의 비밀키로 전자 서명한것) 주셈“

• 클라이언트 측에서 생성한 램덤 데이터

• 클라이언트가 지원하는 암호화 방식들

• 세션 id - 이미 ssl 핸드 쉐이킹을 했다면 기존의 세션을 활용한다

1. 서버 ServerHello
• 서버측에서 생성한 랜덤 데이터， 서버가 선택한 클라이언트의 암호화 방식등 포함한 패킷을 클라이언트로 전송한다
• “그래 이중에 ‘server-choosen-chipher-suite’ 이 방식으로 우리 약속하자”
• SSL 인증서를 세션키로 암호화한 패킷을 클라이언트로 전송한다.
• “인증서 받으셈”
• 서버 공개키 포함한 패킷을 클라이언트로 전송한다.
• “이걸로 드림”

• 서버 측에서 생성한 램덤 데이터

• 서버가 선택한 클라이언트의 암호화 방식
• 암호화 방식에 대한 협상 종료

• 인증서 (서버의 공개키를 포함한다)

1. 클
• 이미 클라이언트가 가지고 있는 CA의 공개키로 인증서를 검증해봄
• “음 잘 까지는걸 보니 조작이 되지 않았군”
• “이제 대칭키를 만들어 서버에 보내고 이걸 세션키로 쓰면 되겠군”
• “까서 나온 서버의 공개키로 암호화 해서 보낸다면 비밀 키를 가진 서버만 나의 대칭키를 까서 쓸 수 있겠군”
• 대칭 키를 생성하여 인증서에 포함된 B의 공개 키로 암호화해서 B에게 보낸다．

1. 서버
• 서버는 클라이언트 가 보내 온 암호화된 대칭 키를 자신의 비밀 키로 복호화 하여 대칭 키를 얻는다．
• “음 클라이언트가 자신의 세션키를 나의 공개키로 잘 암호화 했군”
• “이걸 나만 가지고 있는 비밀키로 까면 클라이언트의 대칭키가 나오겠군”
• “이걸 세션키로 사용하자”