HTTPS

HTTPS는 Hyper-Text Transfer Protocol Secure의 약자로 이름에서 보듯 기존의 HTTP보다 안전한 통신 프로토콜이다.

그럼 무엇으로부터 안전하다는 뜻인가? 지금부터 HTTPS가 무엇으로부터 안전한지 살펴보자

HTTPS가 보장해주는 안전

HTTPS의 장점 중 하나는 내가 다른 사이트에 보내는 정보를 다른 누군가가 훔쳐보지 못하게 하는 것이다.

특정 사이트에 로그인을 한다고 생각해보자. Client는 로그인을 위해 필연적으로 Id와 Password를 Server측에 넘겨주어야 한다.

이러한 방법은 통신중 제 3자가 정보를 가로챌 위험성이 존재한다.

HTTPS는 암호화를 통해 설령 정보의 탈취가 일어나더라도 제 3자가 정보를 해석할 수 없도록 도와준다. 이점은 이뿐만이 아니다.

웹상에서는 서버를 가장하며 클라이언트를 우롱하는 사이트가 여럿 존재한다. 이들의 겉모습에 속아 이들에게 핵심적인 정보를 보내게 하는 방법도 흔히 있는 방법중 하나이다.

하지만 HTTPS를 사용하면 검증된 사이트만 HTTPS 사용이 허가되고, 그렇지 않은 경우 경고가 발생하게 된다.

즉, HTTPS는 다음을 보장해준다.

• 내가 서버에 보내는 정보를 제3자가 볼 수 없게 한다.
• 접속한 사이트가 신뢰성이 있는 곳인지 알려준다.

이제 HTTPS가 어떤 방법으로 이러한 일들을 가능하게 해주는지 살펴보자.

대칭키와 비대칭키

잠깐 과거의 암호화에 대해 살펴보자. 전쟁에서 아군에게 편지를 보낼 때 중간에 적에게 편지를 빼앗겨도 알아볼 수 있도록 하기 위해 2가지 조건이 필요했다.

• 편지의 내용을 암호화해야한다.
• 암호화된 내용은 아군만 읽을 수 있어야 한다.
  

이를 위해 아군측은 해석하는 필터를 미리 준비해놓고 이에 맞추어 정보를 암호화 하는 방법을 이용했다.

대칭키라고 하는 개념은 바로 이 방법에서의 필터의 역할을 의미한다.

양측에서 대칭키를 공유하고 이에 맞춰 메시지를 암호화하고 해석하면 정보를 효과적으로 암호화하여 전달할 수 있다. 대칭키는 바로 이러한 것을 가능하도록 만들어주는 개념이다.

그러나 이러한 방법은 큰 문제점이 존재한다. 바로 대칭키를 어떻게 공유할지에 관한 문제이다.

대칭키도 결국은 양측이 공유해야 사용할 수 있고, 그러기 위해 대칭키를 보내는 중 탈취당하면 제3자가 정보를 마음껏 해석할 수 있기 때문이다.

이러한 문제점에 등장한 개념이 바로 비대칭키를 이용한 암호화이다. 흔히 개인키, 공개키라는 이름으로 불리는 이 방법은 대칭키의 한계를 효과적으로 보완할 수 있었다.

비대칭키를 이용한 보안 방법은 간단하다. 쉽게 풀어쓰자면 A키로 암호화한 데이터는 B키로만 해석할 수 있도록 하는 것이다.

즉, A키의 해석에 필요한 데이터를 B키에만 심어 놓음으로써 B키가 없는 이상 A키로 암호화한 데이터를 해석할 수 없게 만드는 것이다.

여기서 A키는 공개키, B키는 개인키라고 볼 수 있다.

즉, 서버는 개인키를 가지고 있으면서 공개키를 활짝 오픈한다.

공개키는 클라이언트와 제3자가 전부 소유할 수 있으나, 클라이언트에서 공개키로 암호화한 데이터는 개인키를 가지고 있는 서버만이 해석할 수 있다.

즉, 제3자는 서버를 해킹이라도 하지 않는 이상 통신중인 데이터를 탈취하여도 해석할 수 없게 되는 것이다.

HTTPS는 바로 이 방법을 통해 내가 서버에 보내는 정보를 제3자가 볼 수 없게 한다.

사이트의 신뢰성 확보

HTTPS는 신뢰할 수 있는 사이트 여부도 알려준다. 어떤 식으로 구현할 수 있는지 살펴보자.

우리는 위에서 서버가 공개키를 활짝 오픈한다고 살펴보았다. 그러나 서버를 위장한 나쁜 서버에서 서버인척 공개키를 오픈하고 HTTPS방식으로 사용자의 정보를 탈취하는 경우가 생길 수 있다.

이러한 상황에서 나쁜 서버의 공개키로 데이터를 암호화하여 전송한다면 우리는 안좋은 상황을 면치 못할 것이다.

이를 방지하기위해 HTTPS를 사용하는 기관들은 인증기관(CA)로부터 엄격한 인증 과정을 거쳐 공인인증서를 발급받아 서버에 설치해야 한다. 이러한 과정이 없는 사이트는 신뢰할 수 없다고 판단하여 클라이언트에 경고가 표시된다.

크롬, 파이어폭스 등 우리가 사용하는 메이저 브라우저들은 이미 이러한 CA리스트를 가지고 있다.

네이버에 접속하는 상황을 가정해보자. Client는 접속을 하면서도 이 서버가 진짜 네이버인지 의심을 하게 될 것이다.

클라이언트는 서버에 접속하며 HandShake를 시작한다.

먼저 클라이언트가 서버에 데이터를 보내면,

서버 역시 클라이언트에게 통신의 가능성을 알리기 위해 데이터를 보내주어야 한다. 이때 데이터와 함께 인증서를 보내게 된다.

인증기관(CA)는 인증절차를 진행할 때 인증기관의 개인키로 암호화 된 인증서를 서버측에 넘겨주도록 되어있다. 또한 우리가 사용하는 브라우저는 이미 CA의 리스트, 정확히 말하면 CA의 공개키 리스트를 가지고 있다. 따라서 우리의 브라우저는 정상적으로 CA의 인증을 거친 사이트의 인증서를 판별하고 복호화 할 수 있는 것이다.

즉, 클라이언트는 인증서를 받은 시점에서 서버가 CA의 인증을 거친 기관인지 단숨에 파악할 수 있게 된다. 이러한 방법을 통해 HTTPS는 클라이언트에게 통신하는 대상이 믿음직한 대상인지 알려준다.

암호화된 인증서는 오직 CA의 공개키로만 해석할 수 있고, CA의 공개키로 해석할 수 있는 인증서는 오직 CA만(CA의 개인키만)만들 수 있다.

따라서 클라이언트는 신뢰성이 확보된 서버와 HTTPS를 이용해 통신할 수 있게 되는 것이다.

이후 과정에서 클라이언트는 다시 서버의 공개키로 데이터를 암호화하여 데이터를 보내고, 서버는 받은 데이터를 다시 서버의 개인키로 복호화하여 비즈니스를 처리한다.