HTTPS 적용기 (...SSL/TLS)

공부 동기

요즘 어디 웹 사이트를 가나 HTTPS를 적용하지 않은 웹을 보기가 힘들어, 저도 HTTPS를 프로젝트에 적용하면서 좀 더 공부해보았습니다.

 

HTTPS는 HTTP프로토콜과 SSL/TLS의 조합입니다.

---

 

HTTPS 탄생 배경

인터넷상에서 데이터를 전송하는 방식 중에서 가장 일반적인 방법은 HTTP방식입니다. HTTP방식을 이용해 클라이언트와 서버간의 통신이 이루어지게 되는데, HTTP는 통신에서 데이터를 암호화하지 않기 때문에 제 3자에게 데이터가 노출될 가능성이 있습니다. ex)스니핑, Sniffing

 

이러한 위험성으로부터 데이터를 보호하기 위해서 HTTPS가 탄생하였습니다.

 

---

TLS vs SSL

HTTPS의 핵심기술인 TLS와 SSL은 모두 데이터 보안을 제공하기 위한 프로토콜입니다.

SSL은 Secure Sockets Layers의 약자이며

TLS는 Transport Layer Security의 약자입니다.

SSL이 먼저 개발되었으며, 이후에 SSL의 보안적 약점이 발견되어 나온 것이 TLS라고 합니다. 최근에는 대부분 TLS를 이용하고 있으며 SSL은 권장되지 않는다고 합니다.

 

---

 

TLS/SSL 작동과정

1. 클라이언트가 서버에 연결 요청을 보냅니다.

2. 서버는 자신의 공개키와 인증서를 클라이언트로 보냅니다.

3. 클라이언트는 서버의 인증서를 검증하고, 이 인증서가 신뢰할 수 있는 인증 기관에서 발급된 것인지 확인 합니다.

4. 클라이언트는 서버의 공개키를 사용하여 랜덤한 대칭키를 암호화하고 서버에게 전송합니다.

5. 서버는 자신의 개인키를 사용하여 대칭키를 복호화합니다.

6. 이후 클라이언트와 서버는 대칭키를 사용하여 암호화된 데이터를 교환합니다.

7. 서버와 클라이언트는 계속해서 데이터를 교환하며, 모든 데이터는 대칭키를 사용하여 암호화합니다.

 

이러한 과정을 거치기 때문에, 중간에 데이터를 가로채도 암호화된 데이터를 해독할 수 없게 됩니다.

---

 

4번 추가설명 => 클라이언트가 왜 랜덤한 대칭키를 암호화해서 보내야 할까?

대칭키는 하나의 키를 이용해 데이터를 암호화하고 복호화하기 때문에 서버와 클라이언트가 동시에 대칭키를 알고 있어야 합니다., 처음부터 대칭키를 이용하여 통신하게 되면 키가 노출되어 위험하게 됩니다.

때문에, 클라이언트는 서버에서 보낸 공개키를 이용하여 랜덤한 대칭키를 암호화 합니다.

서버의 공개키로 암호화 했기 때문에, 서버는 자신의 키로 클라이언트에서 보낸 대칭키를 복호화 할 수 있게 됩니다.

이제는 클라이언트와 서버가 모두 대칭키를 공유한 상태가 되기 때문에, 해당 대칭키를 이용해 빠르고 안전하게 통신을 이어갈 수 있게 됩니다.

=> 중간에 데이터를 가로채도?? 대칭키를 모르니 복호화가 불가능 합니다.