HTTP와 HTTPS (feat. 대칭키 암호화, 비대칭키 암호화)

HTTP와 HTTPS

개요

웹을 배운다면 HTTP와 HTTPS의 차이는 보안이라는 것은 알 것이다. 이번 포스팅에서는 HTTP가 무엇이고, 문제점은 무엇인지 알아보고 HTTPS는 그 문제점을 어떻게 해결하였는지 알아보도록 한다.

목차

• HTTP
  • GET방식
  • POST방식
• HTTP의 문제점
• HTTPS
• 대칭키 암호화
• 비대칭키 암호화
• HTTPS의 데이터 암호화 과정
• 정리

HTTP

HTTP란 Hyper Text Transfer Protocol의 약자로서, 클라이언트와 서버 사이에서 이루어지는 요청/응답(request/response) 프로토콜이다. 클라이언트와 서버가 통신하기 위해서 서로가 보내는 데이터를 이해할 수 있도록 양식을 정해놓을 필요가 있었고 그렇게 등장한 것이 통신규약, 즉 HTTP이다.

클라이언트가 서버에게 보내는 메세지는 크게 GET방식과 POST방식이 존재한다.

GET 방식

GET방식의 큰 특징은 요청데이터가 URL에 key와 value로 이루어진 Query String으로 표시된다는 것이다.

http://example.com?user=javanitto&pass=java    

여기서 물음표 뒤를 query string이라 부르며 user와 pass라는 키를 가진 두 개의 파라미터가 서버로 전송되는 것이다. 주로 GET방식은 서버에 데이터를 주며 원하는 페이지를 요청할 때 사용된다.

POST방식

POST방식은 GET방식과 다르게 BODY라는 데이터 주머니가 있고 이 주머니에 요청 데이터를 담아서 보낸다.

HTTP 문제점

HTTP의 문제점은 사용자의 데이터에 대한 보안이 약하다는 것이다.

GET방식은 URL에 데이터가 표시되기 때문에 보안에 취약하다. URL에 데이터가 표현되기 때문에 당장의 옆에 있는 사람으로 부터도 보호가 되지 않는다. 이것이 로그인 아이디와 비밀번호라고 생각하면 아주 심각한 보안문제이다.

POST방식은 URL에는 표시되지 않기 때문에 1차적으로 보호는 되지만, 요청메시지에 표현되기 때문에 이것도 보안이 약하다. 참고로 크롬의 개발자도구 network탭을 이용하여 요청메시지를 볼 수 있다.

또한 옛날에는 도메인이름이 비슷한 가짜 사이트에 접속하여 로그인을 요청하는 순간 가짜 사이트의 어드민에게 사용자 정보가 전달되는 피싱사이트가 많았고 피해자도 많았다.

HTTPS

HTTPS의 S는 Secure의 약자로 HTTP에 보안기능이 추가된 것이다. HTTPS는 접속한 사이트가 신뢰할 수 있는 사이트인지 검증해주고 클라이언트가 서버로 보내는 요청데이터를 암호화하여 전송하기 때문에 중간에서 데이터를 가로채어도 보호 할 수 있다. HTTPS는 데이터를 암호화하는 방식으로 대칭키 방식과 비대칭키 방식을 사용한다.

대칭키 암호화

대칭키 암호화란 하나의 키로 암호화 복호화 할 수 있는 것을 말한다. 즉, 데이터를 주고받는 두 개체가 서로 같은 모양의 키를 가지고 있고 클라이언트에서 대칭키로 데이터를 암호화 하여 서버로 전송하면 서버는 똑같이 생긴 대칭키로 데이터를 복호화하여 읽는 것이다.

하지만 한 가지 문제점이 있다. 데이터를 주고받기 위해 키를 가지고 있는 개체가 다른 한 개체에게 키를 전달하는 과정이 필요한데, 이 때 이 키를 중간에서 가로챈다면 보안이 유명무실해진다는 것이다.

비대칭키 암호화

대칭키 암호화 방식을 보완하여 등장한 것이 비대칭키 암호화 방식이다. 이 방식은 공개키(Public Key)와 개인키(Private Key)가 하나의 쌍을 이루고 있고 한쪽이 암호화를 하면 한 쪽이 복호화를 맡는다. 암호화 키와 복호화 키의 모양이 다르기 때문에 비대칭키라고 불린다.

만약 공개키로 암호화를 하는 방식이라면 데이터 보안에 중점을 둔 것이고, 개인키로 암호화하는 방식이라면 안전한 전자서명을 통한 인증 과정에 중점을 둔 것으로 해석할 수 있다.

비대칭키 암호화는 자신이 개인키를 가지고 있고 데이터를 주고받기 위해 공개키를 전달한다. 중간에서 공개키를 가로채더라도 이 키로 암호화 복호화를 모두 할 수는 없기 때문에 대칭키보다 보안이 강력하다.

HTTPS의 데이터 암호화 과정

사이트에 접속하게되면 데이터를 전송하기 전에 이 사이트가 신뢰할 수 있는 사이트인지, 정확히 말하면 가지고 있는 공개키가 신뢰할 수 있는 공개키인지 확인해야한다. 이해하기 쉽게 클라이언트를 '나', 서버를 'NAVER'로 하자.

내가 NAVER에 접속을 시도한다고 할 때 해당 사이트가 가짜 사이트일 수 있다. 신뢰 할 수 있는 사이트인지 확인을 위하여 다음의 Handshake과정을 거치게 된다.

설명하기에 앞서 CA란 Certificate Authority의 약자로 공개키가 인증된 서버의 키인지 인증해주는 인증기관이라는 것을 알아두자. 우리가 흔히 사용하는 브라우저에는 CA의 목록들과 각 CA에서 발급한 공개키들을 가지고 있다.

1. Chrome(클라이언트)이 NAVER(서버)에게 무작위의 데이터를 전송한다.

2. NAVER는 Chrome으로 부터 받은 데이터를 보관하고 응답으로 NAVER에서 생성한 무작위의 데이터와 함께 NAVER에서 이용하고 있는 CA의 개인키로 암호화한 인증서를 보낸다.

3. Chrome은 NAVER가 전송한 인증서와 무작위 데이터를 저장하고, 가지고 있는 CA목록들의 공개키로 인증서를 복호화 한다.

4. 복호화한 인증서에는 해당 서버의 공개키가 들어있다.

5. 만약 복호화가 불가능 하다면 해당 서버는 CA에서 인증된 서버가 아니기 때문에 브라우저 주소창에 경고아이콘이 뜨게 된다.

이 Handshake를 통해 Chrome은 신뢰할 수 있는 NAVER의 공개키를 얻었다. 이제 이 공개키로 데이터를 주고 받으면 될 것같지만 실제로 그렇게 하지 않는다. 왜냐하면 비대칭키 방식으로 대량의 데이터를 일일이 암호화, 복호화를 하면서 주고받기에는 자원이 많이 소모되기 때문이다.

Handshake과정 1번과 2번을 통해 NAVER와 Chrome은 서로가 생성한 무작위 데이터를 가지고 있다. Chrome은 NAVER의 공개키로 가지고 있는 두 무작위 데이터를 암호화하여 NAVER로 보낸다. 그 다음 NAVER와 Chrome은 각자 일련의 과정을 거쳐 해당 무작위 데이터들을 같은 모양의 대칭키로 만든다.

정리

• 대칭키 암호화 방식은 중간에서 탈취당했을 때 데이터 보안이 위협된다.

• 비대칭키 암호화 방식은 공개키와 개인키의 쌍으로 이루어져 있고 한쪽은 암호화, 한쪽은 복호화를 한다.

• 공개키는 탈취당해도 보안에 위협되지 않는다.

• 클라이언트는 CA로부터 인증된 서버로 부터 공개키를 받기위해 Handshake과정을 거친다.

• 비대칭키 방식을 통해 클라이언트와 서버는 안전하게 대칭키 암호화 방식을 사용할 수 있게된다.