http VS https 차이점 및 SSL 원리

http

• http 는 HyperText Transfer Protocl의 약자로, Application layer의 프로토콜이다. 서버와 클라이언트가 데이터를 서로 주고받기 위해 만들어졌다. http는 client-server 모델을 따른다.
  • client가 요청을 위해 연결을 시작하며 서버로부터 응답이 올때까지 대기한다.
• http는 stateless 프로토콜이며, 이는 서버가 클라이언트로 부터 받는 각 요청은 어떠한 요청과도 연관되어 있지 않다는것을 의미한다.
  • 이게 무슨 뜻이냐면 특정 작업을 해두지 않으면 클라이언트는 로그인을 완료한 뒤, 다음 요청을 할 시 로그인했다는 증거가 남아있지 않아 로그인 처리가 기억되지 않는다는 뜻.
• 또한 http는 connectionless하다. 비연결지향 프로토콜.
  • 특정 단위 시간동안 수천, 수만명이 서비스를 사용한다고 하더라도 실제 서버에서 동시에 처리하는 요청은 이보다 훨씬 적다.
    • 왜?: 브라우저에 검색버튼을 연타하지 않음, 로그인후 바로 로그아웃, 바로 로그인 반복을 하지 않음. => 클라이언트를 사용하는 인간은 정보를 습득하고 다음 액션을 취하기 까지 물리적인 시간이 필요하기 때문.

• 참고로 http는 3.0 이전 버전은 TCP기반, 3.0이후 버전은 UDP기반으로 만들어졌다.

https

• https 는 HyperText Transfer Protocol Secure의 약자로, 표준 http와 동일한 방식으로 작동하며 기존의 http는 서버에서부터 브라우저로 전송되는 정보가 암호화되지 않는 문제점이 있었지만 https는 여기에 SSL(보안 소켓 계층)을 사용해 추가적인 보호를 제공한다. 따라서 개인 데이터를 훔치거나, 해킹할 수 없도록 작동한다.
  • http에 암호화가 추가된 프로토콜.
• https는 http와는 다르게 443번 포트를 사용한다.
• 아래에서 SSL이 어떤식으로 작동하는지 알아보도록 하겠습니다.

• https는 옛날에 전자상거래와 관련된 사이트에서 주로 사용되었지만, 구글에서 https의 장려를 위해 https를 사용하는 웹사이트에 대해 구글 검색 순위 반영에 가산점을 주겠다고 발표도 하며 https사용을 장려했다.

SSL

• Secure Sockets Layer의 약자로 Transport Layer Security(TLS)라고도 한다.
• 클라이언트와 서버가 네트워크로 통신하는 과정에서 도청, 간섭, 위조를 방지하기 위해 설계되었다.
• SSL의 새로운 버전이 TLS인거 같은데 SSL이라는 이름으로 더 많이 사용되고 있는거 같다.
• SSL인증서는 클라이언트와 서버가 통신을 할 때 제 3자가 보증을 해주는 문서이다.
• SSL을 통해 아래와 같은 목적을 달성할 수 있다.
  • 전달되는 정보의 노출을 막을 수 있다.
  • 클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버인지 확인할 수 있다.
  • 전달되는 정보의 위조를 막을 수 있다.
• 암호화에는 두가지 종류가 존재하며 대칭키 방식과 공개키(비대칭키) 방식이 있다.
  • 대칭키 방식에는 최초 공유할 때 보안상의 취약점이 있어 대칭키를 공유하기 위해 공개키(비대칭키) 방식을 사용하며 이를 통해 대칭키를 공유한 이후 부터는 대칭키를 사용한다.
  • 공개키(비대칭키)를 계속 사용하지 않는 이유는 작업의 부하가 심하기 때문!

대칭키

• 서버와 클라이언트가 같은 키를 가지고 특정 데이터를 암호화 및 복호화를 할때 사용하는 키를 대칭키라고 한다.
  • 특정 데이터를 암호화할 때에도 대칭키를 사용해 암호화 하고, 복호화를 할 때도 같은 대칭키를 사용해 복호화 할 수 있다.
• 하지만 대칭키는 한가지 단점이 존재하는데, 결국 한번은 공유를 해야하므로 이때 키가 외부에 노출되는 한계가 존재한다.
• 이를 보안해서 나온 개념인 비대칭키가 있으며 공개키, 비밀키 라고 부른다.

• 늘 그렇듯이 장점이 있으면 단점이 있듯 비대칭키(공개키, 비밀키) 또한 단점이 존재하는데 비대칭키는 작업의 부하가 크다는 단점이 존재한다.
• 따라서 앞서 말한 대칭키의 단점인 키를 최초에 한번 공개할 때 이 비대칭키(공개키, 비밀키) 방식을 사용해 공개하며 이후 통신에서는 대칭키 방식을 사용한다.

비대칭키(공개키, 개인키) 원리

• 비대칭키 는 공개키라고 불리우며 공개키와 개인키는 한 쌍으로 존재한다(서로 다르기때문에 비대칭키).
• 서버는 비대칭키중 하나를 보관하며 이를 개인키라 부른다.
• 나머지 하나를 클라이언트에 보내며 이를 공개키라고 부른다.
• 클라이언트는 공개키를 이용해 평문을 암호화해 서버로 보낸다.
  • 이미 공개되버린 공개키로는 이 암호가 탈취되어도 해독이 불가능하다.
  • 추가로, 서버가 처음에 뿌린 공개키가 클라이언트가 요청한 서버의 공개키인지 클라이언트 입장에서도 아직 신뢰할 수 없다. -> 클라이언트 입장에서 신뢰된 서버인지 확인하기 위해 공개키의 정품 인증 식별이 필요함.

• 아래부터는 클라이언트와 서버가 최초 접속시 공개키(비대칭키)를 통해 대칭키를 공유하는 과정을 나타낸다.
  • 추가로 Certificate Authority(CA)라는 단어가 나오는데 미리 까다로운 절차를 통해 신뢰받는 기관으로 디지털 인증서를 제공하는 공인된 기업이다.

CA (Certificate Authority)

• 디지털 인증서를 제공하는 공인된 기업 (Certificate Authority).
  • 인증서는 CA의 개인키로 암호화 되어 있으며 CA의 정보(CA의 공개키등)와 함께 클라이언트의 웹브라우저에 저장되어 있다.
    • 여기서 주의해야 할 점은 서버의 개인키가 아닌 CA의 개인키로 암호화 되어 있다!
• 지금 설명한 이부분은 당장 이해가 안될수도 있는데 일단 계속 읽다가 나중에 다시 읽어야 하는 부분이 나오니 잠시 넘어가도 괜찮습니다.

handshake (악수)

• client hello -> server hello -> pre master secret -> master secret 단계로 나뉘어 진다.

Client hello

• 클라이언트가 서버에 접속하는 단계로, 이때 클라이언트가 서버에 주는 정보는 다음과 같다.
  • 클라이언트에서 생성한 랜덤 데이터
    • 랜덤 데이터이지만 나중에 공개키를 생성할때 쓰이며 외부에 노출되어서는 안된다. 추가로 클라이언트 또한 이 데이터를 보관하고 있는다.
  • 클라이언트가 지원하는 암호화 방식들
    • 클라이언트와 서버가 지원하는 암호화 방식이 다를 수 있으므로 클라이언트는 처음에 브라우저가 지원하는 암호화 방식의 명단을 같이 보낸다.
  • 세션 아이디
    • 자원의 절약을 위해 이미 SSL 악수를 했다면 기존의 세션을 재활용함.

Server hello

• client hello에 대한 서버의 응답이며, 이때 서버가 클라이언트에 주는 정보는 다음과 같다.
  • 서버 측에서 생성한 랜덤 데이터
    • 랜덤 데이터이지만 나중에 공개키를 생성할때 쓰이며 외부에 노출되어서는 안된다. 추가로 서버 또한 해당 데이터를 보관하고 있는다.
  • 서버가 선택한 클라이언트가 보낸 암호화 방식중 한가지
    • 클라이언트가 보낸 사용가능한 암호화 방식중 서버는 가장 안전한 암호화 수단 방식을 결정후 서버에게 선택한 암호화 방식을 앞으로 사용하기로 보낸다.
  • 인증서(서버의 공개키가 담겨져 있음).
    • 서버가 보낸 CA의 비밀키로 암호화된 인증서를 클라이언트는 본인의 브라우저에 저장되어 있는 CA의 공개키로 복호화가 가능하다(위의 CA설명 부분을 다시보면 이해에 도움이 됩니다).
    • 복호화에 성공하면 이는 CA의 개인키로 암호화된 문서임이 증명된 것이며 인증서를 전송한 서버를 신뢰할 수 있음을 의미한다. 서버에서 클라이언트에 제공하는 공개키(비대칭키)가 나온다.
    • 만약 위조된 인증서를 받아 CA의 공개키로 복호화 되지 않는다면 Not secure 화면이 나타난다.

Pre master secret

• 위 단계를 거쳐 클라이언트는 서버에서 제공하는 공개키(비대칭키)를 안전하게 받을 수 있으며, 해당 공개키는 Pre master Secret을 암호화 하는데 사용한다
  • Pre master Secret: client hello server hello에서 생성된 두개의 다른 랜덤값을 조합해 생성된 키.
• Pre master Secret을 암호화 하는 이유는 pre master secret을 서버로 보낼건데 이때 외부에 노출되면 안되기 때문이다.

Master secret

• Pre master Secret을 공개키로 암호화한 후 이를 서버로 보내며 서버는 이것을 받은 뒤 개인키로 복호화 한 다음 일련의 과정을 거쳐 Master secret을 생성한다.
  • master secret을 생성하는 과정은 서버와 클라이언트 양쪽에서 이루어지며 같은 값이 나온다.
• 또한 master secret은 session key를 생성하며 이 키를 이용한 대칭키 방식으로 통신을 할 수 있다.

Session

• 위의 master secret까지가 handshake 과정이며 이를 통해 받은 session key를 이용해 대칭키 방식으로 서버와 클라이언트는 통신을 주고받는다.

Session terminating

• 통신이 끝난다면 세션을 폐지해 더이상 해당 세션을 사용하지 못하도록 처리할 수 있다.

References

• https://developer.mozilla.org/en-US/docs/Web/HTTP
• https://www.youtube.com/watch?v=8R0FUF_t_zk&t=11s
• https://www.youtube.com/watch?v=H6lpFRpyl14