[네트워크] HTTPS

Hyper-Text Transfer Protocol Secure

HTTP와 TLS로 보안된 통신을 하는 프로토콜

 

목적:

1. 두 통신 당사자가 서로 신뢰할 수 있는지 확인

2. 통신 내용이 제 3자에게 도청되는 것을 방지

 

서로의 신원을 확인하고 통신 암호화에 사용할 세션 키를 공유하기 위한 Handshake 과정을 거침

1. ClientHello - 클라이언트가 먼저 서버에게 인사

random(32byte 난수 값), session ID, cipher suites (클라이언트에서 사용 가능한 암호화 알고리즘 목록), 사용 가능한 TLS version 등을 같이 보냄

2. ServerHello - 서버가 클라이언트에게 인사

random(32 byte 난수 값), session ID, 선택된 cipher suite, 선택된 TLS version 을 보냄

3. Certificate - 서버가 클라이언트에게 서버의 인증서를 보냄 

4. ServerHelloDone - 인증서 전송이 끝났음을 알림

- 클라이언트는 해당 인증서를 검증함 : CA(Certificate Authority)에 확인.

신뢰할 수 있는 인증서는 CA의 private key로 암호화되어있기 때문에, 브라우저가 가진 public key로 복호화가 가능함 

- 인증서를 성공적으로 복호화하면 서버의 공개 키를 얻게 됨. 

- 클라이언트는 자기가 생성한 random과 서버로부터 받은 random을 이용하여 pre-master secret을 만들고, 서버의 공개키로 암호화

5. ClientKeyExchagne - 암호화된 pre-master secret을 전송함

- 서버는 자신이 가진 private key로 암호화된 pre-master secret을 복호화하고, master-secret을 만듦

- 클라이언트도 가지고 있는 pre-master secret으로 master-secret을 만듦

- 서버/클라이언트는 master-secret으로 session key를 만듦.

=> 서버, 클라이언트가 동일한 세션 키 (대칭 키)를 가지게 됨!

6. ChangeCipherSpec - 앞으로의 모든 통신이 세션 키를 사용해 암호화해 보낼것을 알려줌

7. Finished - 핸드셰이킹이 끝났음을 알림

 

 

TLS는 대칭키와 비대칭키를 혼합해서 사용하는 방식

 

Q. 왜 비대칭키가 더 안전한데 통신할 때 비대칭키를 안쓸까?

A. 비대칭키는 암호화/복호화 할 때 하드웨어가 일을 많이해야함. 매 통신마다 비대칭치로 일일히 암호화/복호화 하는건 무리

 

Q. 대칭키는 탈취당할 수 있어서 위험한거 아님?

A. 대칭키를 공유하는 과정에서 비대칭키로 암호화/복호화를 하므로(pre-master secret), 중간에 탈취당해도 private key가 없으면 대칭키를 얻을 수 없음