개요

이건 나만의 접근 방식으로 정리한 글이다.
나는 누구라도 이해하기 쉽고 기억하기 쉬운 글을 쓰는걸 잘한다.
자신감을 가지자.

HTTP

HTTP란 이전에도 정리한 적이 있듯이 Hyper Text Transfer Protocol의 약자이다.

웹의 창시자 버너스 리는 정보들의 형식으로 HTML, 특정 자원을 식별하기 위한 수단으로 URI 그리고 이들을 교환하기 위한 수단으로 HTTP를 고안하였다.

HTTP는 요청과 응답으로 되어있다. 클라이언트가 요청을 하면 서버가 응답을 하고 통신을 종료한다.

맥북을 기준으로 curl 명령어를 입력하여 테스트 해볼 수 있다.
curl[옵션][url]의 형식으로 다음과 같이 사용한다.

curl -X GET /index.html Host: example.com

http 프로토콜은 애플리케이션 계층의 프로토콜로 이 요청은 전송 계층에서 TCP프로토콜을 통해 전달된다.
TCP는 데이터를 세그먼트라는 단위로 나눈다.
이 세그먼트들은 순서가 정해져서 받는 쪽에서 정확한 순서대로 재조립할 수 있도록한다.
TCP는 송신 측과 수신 측간에 안정적인 연결을 설정한다. 이를 3-way-handshake라고 한다.

TCP 세그먼트는 IP프로토콜에 의해 패킷으로 변환된다.
패킷에는 송신자와 수신자의 IP주소가 포함되며 대상 서버로 전달된다.
이제 이 패킷은 데이터 링크 계층에서 프레임으로 변환되어 네트워크 인터페이스를 통해 전송된다.
이 프레임이라는 것은 케이블이나 무선 신호를 통해 전송된다.

자, 이렇게 서버 측에 전송이 되었다.
그럼 서버 측에서는 역순으로 원래 데이터로 복원시킨다.

그러나.. 비밀을 알고싶어하는 사람들이 꼭 있기 마련이다.
맞다. 해커들은 주로 패킷을 가로채는 식으로 공격을 시도한다.
패킷은 전송하려는 데이터를 담고 있으며 이를 분석하여 사용자의 요청, 응답, 메시지 내용등을 확인할 수 있다.
내가 누군가에게 메일을 보내는 내용, 개인정보등을 누군가가 볼 수 있는 것이다.

따라서 대책이 필요하게 된다.

HTTPS

HTTPS는 HTTP + Secured 라는 의미로 보안이 강화된 HTTP프로토콜을 말한다.
한 번 생각해보자. 보안을 어떻게 강화할 수 있을까?
대표적으로 암호화가 있다.
보내려는 정보를 암호화하여 전송한다. 그리고 이 암호를 해독하여 원래의 정보를 얻는다.
이게 가능하려면 일종의 암호화 키가 필요하다.
일정한 규칙(암호화 키)을 통해 암호화한 뒤 받는 쪽에서 동일한 규칙(같은 암호화 키)을 사용해 해독한다. 이러한 방식을 대칭키 방식이라고 한다. 대칭키 방식이란 암호화 키와 복호화에 사용되는 키가 동일한 경우를 말한다.

그러나 이러한 방식에는 여러 문제가 있는데 암호화 키와 복호화 키가 동일하다면 이 키를 전송하는 과정에서 누군가가 키를 가로챈다면 암호화된 데이터를 해독할 수 있게 된다.
어느 쪽에서 규칙을 생성하더라도 결국 그 규칙은 서로가 공유해야하기 때문에 통신 과정을 거쳐야한다.

따라서 다른 방법을 고려해봐야한다. 만약 이 대칭키 자체를 암호화해서 보낼 수 있다면?

여기서 적용되는 개념이 바로 비대칭키다.
비대칭키는 공개 키와 개인 키라는 두 개의 키를 사용한다.
공개 키란 누구나 접근할 수 있도록 공개된 키고 개인 키란 소유자만 알고 있는 비밀키다.

클라이언트가 통신을 시작할 때 데이터를 암호화하기 위해 대칭키를 생성한다.
클라이언트는 이 대칭키를 서버의 공개 키를 사용하여 암호화하여 서버로 전송한다.
이렇게 암호화된 데이터는 서버의 개인 키로만 복호화할 수 있다.
서버는 클라이언트가 보낸 암호화된 대칭키를 자신의 개인 키로 복호화한다.
서버는 이 키를 저장하고 이후 클라이언트와 서버는 이 대칭키를 사용하여 데이터를 암/복호화하여 통신한다.

SSL/TLS

SSL은 1990년대에 개발된 프로토콜로 이후 TLS로 발전하지만 유사성과 역사적 이유로 이 둘을 묶어서 언급한다.

  1. CA(인증 제공 업체)에서 해당 인증서를 발급해준다.
  2. 이 인증서를 서버에 설치한다.
  3. 브라우저는 인증서를 확인하여 해당 서버가 신뢰할 수 있는 기관에 의해 인증받았는지 검증한다.
  4. 클라이언트가 서버에 연결을 시도하면 서버는 자신의 인증서를 클라이언트에게 제공한다.
  5. 클라이언트는 인증서를 검증하고 서버와 안전하게 통신하기 위해 TLS세션 키를 설정하고 암호화된 데이터를 주고받는다.

정리

  1. 클라이언트가 서버에 보안 연결을 시작하려고 요청한다. 여기에는 사용할 수 있는 TLS/SSL 버전, 암호화 알고리즘 목록, 무작위 난수가 포함되어있다.
  2. 서버가 클라이언트의 요청을 수락하고 보안 연결을 설정하기 위해 응답한다. 서버는 자신이 선택한 알고리즘과 서버의 인증서 그리고 무작위 난수를 보낸다. 이 난수들은 세션키의 재료가 된다.
  3. 클라이언트는 서버가 보낸 인증서를 검증한다. 여기에는 서버의 공개 키와 서버 신원을 확인할 수 있는 정보가 포함되어있다.
  4. 서버가 보낸 인증서의 유효성 검증에 실패하면 이 사이트는 신뢰할 수 없다는 문구가 표시된다.
  5. 위에서 교환한 난수들 외에 클라이언트는 Pre-Master Secret을 생성하고 이를 서버의 공개키를 사용해 암호화하여 서버로 전송한다. 이렇게 하면 효율적으로 서로 동일한 키를 가질 수 있게 된다.
  6. 서버는 클라이언트가 보낸 암호화된 대칭키를 자신의 개인 키로 복호화한다.
  7. 서버는 키를 저장하고 이후의 통신에는 이 대칭키를 사용하여 데이터를 암/복호화하여 통신한다.핸드 셰이크 종료
  8. 세션이 끝나거나 일정 시간이 지나면 해당 키를 파기한다.
  9. 다시 세션이 시작되면 위의 과정을 거쳐 키를 교환한다.