HTTPS

HTTP의 취약점

 

1. 암호화 되지 않은 통신이기 때문에 도청 가능

HTTP를 사용한 리퀘스트, 리스폰스 통신 내용은 암호화 되지 않고 평문으로 통신하게 된다.

 

2. 통신 대상을 확인하지 않기 때문에 위장 가능

HTTP에 의한 통신은 상대가 누구인지 확인하는 처리가 없기 때문에 누구든지 리퀘스트를 보낼수 있고, 리퀘스트가 오면 상대가 누구든지 리스폰스를 반환하게 된다.

 

3. 완전성을 증명할 수 없기 때문에 변조 가능

리퀘스트, 리스폰스가 발신 된 후에 상대가 수신하는 사이에 메시지 내용이 변조되어도 알수가 없다.

 

 

HTTP + 암호화 + 인증 + 완전성 보조 == HTTPS

 

HTTPS

HTTP통신을 담당하는 소켓이 SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security) 프로토콜을 통해서 통신을 대체 하는것이며, 이는 모두 애플리케이션 계층에 속한다.

 

1. 서버의 공개키를 인증 기관에 등록

2. 인증 기관의 비밀키로 서버의 공개키에 디지털 서명으로 공개키 증명서를 작성 등록

3. 서버의 공개키 증명서를 입수하고, 디지털 서명을 인증 기관의 공개 키로 검증하고, 공개키가 진짜 인지 확인

4. 서버의 공개키로 암호화해서 메시지를 송신 기관에 등록

5. 서버의 비밀키로 메시지를 복호화

 

HTTPS통신 구조 순서

1. Handshake: Client Hello

클라이언트가 ClientHello 메시지를 송신하면서 SSL통신을 시작한다.

메시지에는 클라이언트가 제공하는 SSL의 버전을 지정하고, 암호 스위트(Cipher Suite)로 불리는 리스트(사용하는 암호화의 알고리즘이나 키 사이즈) 등이 포함되어 있다.

 

2. Handshake: Server Hello

서버가 SSL통신이 가능한 경우에는 Server Hello메시지로 응답한다.

클라이언트와 같이 SSL버전과 암호 스위트를 포함한다. 서버의 암호 스위트 내용은 클라이언트에서 받은 암호 스위트의 내용에서 선택된 것

 

3. Handshake: Certificate

서버가 Certificate 메시지를 송신한다. 메시지에는 공개키 증명서가 포함되어 있다.

 

4. Handshake: ServerHelloDone

서바가 Server Hello Done 메시지를 송신하여 최초의 SSL협의가 끝났음을 통지한다.

 

5. Handshake: ClientKeyExchange

클라이언트가 Client Key Exchange 메시지로 응답한다. 메시지에는 통신을 암호화하는데 사용하는 Pre-Master secret이 포함되어 있다. (이 메시지는 3. Handshake: Certificate의 공개키 증명서에서 꺼낸 공개키로 암호화 되어있음)

 

6. ChangeCipherSpec

클라이언트는 Change Cipher Spec 메시지를 송신한다. 이 메시지 이후의 통신은 암호키를 사용해서 진행한다.

 

7. Handshake: Finished

클라이언트는 Finished 메시지를 송신한다. 이메시지는 접속 전체의 체크 값을 포함하고 있으며, 통신협상에 성공했는지 여부는 서버가 메시지를 올바르게 복호화 할수 있는 여부가 결정된다.

 

8. ChangeCipherSpec

서버에도 Change Cipher Spec 메시지를 송신 한다.

 

9. Handshake: Finished

서버에서도 Finished 메시지를 송신 한다.

 

10. Application Data (HTTP)

서버와 클라이언트의 Finished 메시지가 교환되면 SSL에 의해서 접속은 확립 되며, 통신은 SSL에 의해서 보호되고 있는 상태이다. 이제부터 애플리케이션 계층의 프로토콜에 통신을 한다. HTTP 리퀘스트/리스폰스

 

11. Alert: warning, close notify

마지막에 클라이언트가 접속을 끊는다. 접속을 끊을 경우에는 close_notify메시지를 송신한다.

그 후에  TCP FIN 메시지를 보내 TCP통신을 종료한다.