web

HTTP와 HTTPS의 차이점에 대해서 알아보자

키위먹고싶다 2022. 1. 14. 21:54

지난 글에서 HTTP의 발전 과정에 대해 설명했다. 

HTTP의 구조와 버전 차이점에 대해 적었는데 오늘은 HTTPS에 대해서 정리하겠다.

HTTPS란?

HTTPS는 Hypertext Transfer Protocol Secure의 약자로 HTTP프로토콜의 보안버전이다. 

 

HTTP통신에서 html같은 단순 텍스트를 주고 받을 때를 생각해보자. 

계좌번호나 비밀번호와 같은 중요한 데이터들이 네트워크상에서 노출된다면 큰 문제가 발생할 수 있다.

HTTPS는 데이터를 암호화 시켜서 보안상의 문제를 해결하여 데이터를 안전하게 주고받을 수 있다.

HTTP에 데이터 암호화가 추가된 프로토콜이라고 이해하자.

 

암호화

 

대칭키

 

암호화에 쓰이는 키와 복호화에 쓰이는 키가 동일하다. 간편하고 비용이 적다는 장점이 있지만 하나의 키로 암호가 되어있기 때문에 키가 유출되면 데이터가 해커에 의해 복호화된다는 치명적인 단점을 가지고 있다. 

 

 

공개키(비대칭 키)

 

공개키와 개인키(비밀키) 2가지 키를 사용한다. 공개키로 암호화하면 개인키로 복호화 할 수 있고, 개인키로 암호화 하면 공개키로 복호화 할 수 있다. 대칭키보다 안전하지만 cpu리소스를 크게 소모한다. 

 

 

Https 통신에서 실제 전송되는 데이터의 암호화에는 대칭키 암호화 방식을 사용하고, 

키 교환에는 비대칭키 암호화를 사용하여 처리 속도가 느린 문제를 해결한다. 

 

 

1. 내가 사이트에 보내는 정보들을 제 3자가 못보게 한다.

2. 접속한 사이트가 믿을 맏한 곳인지를 알려준다,

 

먼저 사이트는 개인키가 아닌 공개키를 사용자들에게 뿌리고 

사용자는 뿌려진 공개키를 사용해서 데이터(비밀번호)를 암호화해서 사이트에 보낸다. 

이때 다른 사용자가 같은 공개키로 이 암호문을 복호화를 시도해도 

암호문을 복호화 할 수 있는 개인키는 사이트만 가지고 있다. 그니까 사용자가 보낸 암호문을

볼 수 있는것은 사이트뿐이다.

 

이 원리로 우리는 개인 정보들을 안심하고 사이트에 보낼 수 있다.

근데 이 사이트가 사용자가 원하는 사이트가 맞는지 어떻게 증명할까??

 

사이트가 사용자에게 보내는 정보들은 그 일부가 사이트의 개인키로 암호화 되어있다.

사용자는 공개키만 가지고 있기 때문에 이 정보들을 열 수 없다. 

 

그래서 신뢰할 수 있는 기관에게 이것이 사이트가 보낸 공개키가 맞다는 사실만

검증하면 우린 안전하게 사이트를 이용할 수 있다.

 

 

 

일단 사이트가 보낸 공개키가 이 사이트의 진짜 공개키가 맞는지 알아야 한다.

다른 사이트가 보낸 공개키일수도 있기 때문이다. 

이것을 인증해주는 공인된 인증기관인 CA가 있다. 

 

클라이언트는 처음 서버에 접속할때 아직 서버를 신뢰하지 않는다. 

그래서 서로 탐색 과정을 거친다. handshake

클라이언트는 어떤 랜덤 데이터를 생성해서 서버에 보내고 이것을 받은 서버는 답변으로

서버측에서 생성한 무작위 데이터와 해당 서버의 인증서를 실어서 보낸다. 이것이 악수이다. 

 

그럼 클라이언트는 이 인증서가 진짜인지 브라우저에 내장된 CA들의 정보를 통해서 확인하게 된다.

비대칭키 방식을 사용해서.

 

CA의 인증을 받은 인증서들은 해당 CA의 개인키로 암호화가 되어있다. 

이게 진짜면 브라우저에 저장된 그 CA의 공개키로 복호화 할 수 있어야 한다. 

만약 CA의 리스트 중에 이 인증서가 해당하는 것이 없다면 브라우저 주소창에 표시가 뜬다. 

만약 리스트에 해당하는 인증서가 성공적으로 복화되면 그 인증서에 있는 사이트의 공개키가 포함되어있다.

 

클라이언트는 아까 악수할때 생성된 무작위 두개의 데이터들을 혼합해서 임시키를 만들고

이 임시 키는 서버의 공개키로 암호화돼서 서버로 보내지고 양쪽에서 일련의 동일한 과정을 거쳐 동일한 대칭키가 완성되는 것이다. 이제 이 대칭키는 서버와 클라이언트 둘만 가지고 있기 때문에 이 이후 서로 주고받아지는 메시지들을 대칭키 방식을 사용해도 제 3자가 알아볼 걱정이 없다. 

 

 

 

SSL

HTTPS는 TCP위에 놓인 보안계층(SSL)위의 HTTP이다

SSL계층은 Secure Sockets Layer(보안 소켓 계층)이다.

 

SSL인증서

  • 클라이언트와 서버간의 통신을 공인된 제 3자업체(CA)가 보증해주는 전자화된 문서.

역할

  • 통신 내용이 노출되거나 변경되는 것을 방지한다.
  • 클라이언트가 접속하려는 서버가 신뢰 할 수 있는 서버인지 확인할 수 있다.
  • SSL통신에 사용할 공개키를 클라이언트에게 제공한다.

 

SSL에서는 대칭키와 비대칭키 암호화 방식을 사용한다.

 

SSL에서는 암호화된 데이터를 전송하기 위해서 공개키와 대칭키를 혼합해서 사용한다. 즉 클라이언트와 서버가 주고받는 실제 정보는 대칭키 방식으로 암호화하고, 대칭키 방식으로 암호화된 실제 정보를 복호화할 때 사용할 대칭키는 공개키 방식으로 암호화해서 클라이언트와 서버가 주고 받게 된다. 그런데 공개키가 진짜인지 가짜인지 증명할 수 없으며 다른사람이 공개키를 바꿔치키 했을 경우 문제가 생긴다. 이를 해결하기 위해 위에서 설명한 공개키 증명서인 SSL인증서를 사용한다.

 

SSL인증서를 사용한 HTTPS통신 과정

  1. 서버는 공개키와 개인키를 만들고, 인증기관 CA에 자신의 정보와 공개키를 관리해달라고 계약한다.
  2. 인증기관만의 공개키와 개인키가 있는데 인증기관은 서버가 제출한 데이터를 검증하고 인증기관의 개인키를 사용해서 제출된 데이터를 암호화한 인증서를 서버에게 제공한다.(서버는 인증서를 가지게 됨)
  3. 인증 기관은 클라이언트에게 자신의 공개키를 제공한다.
  4. 클라이언트가 서버에 접속하면 서버는 2번에서 받았던 인증서를 클라이언트에게 전송한다.
  5. 클라이언트는 3번에서 받은 인증기관의 공개키로 인증서를 해독해서 검증한다. 그래서 사이트의 정보와 서버의 공개키를 알 수 있게 된다. 
  6. 이렇게 얻은 서버의 공개키로 대칭키를 암호화해서 다시 서버에 전송한다.
  7. 서버는 개인키로 암호문을 해독하여 대칭키를 얻게 되고, 대칭키로 데이터를 주고받게 된다.