http와 https에 대해 알아보자
최근 프로젝트를 EC2로 배포를 하였는데, https
가 적용되어있지 않아서, ‘주의 요함’, ‘이 사이트는 보안 연결(HTTPS)이 사용되지 않았습니다.’ 라는 문구를 볼 수 있었다. 그래서 https
는 http
와 어떤 차이가 있고, 어떻게 보안 문제를 해결하였는지 궁금해졌다. 그래서 이번 시간에는 http
와 https
의 차이를 알아보고자 한다.
HTTP(HyperText Tranfer Protocol)
http
는 WWW 상에서 정보를 주고 받는 프로토콜이다. 프로토콜은 컴퓨터나 원거리 통신 장비 사이에서 메시지를 주고 받는 양식과 규칙의 체계를 뜻하는데, http
는 웹브라우저(Client)와 서버(Server)간의 웹페이지같은 자원을 주고 받을 때 쓰는 통신 규약이라고 생각하면 된다.
그래서 http
를 사용해서 클라이언트인 웹브라우저는 서버에 웹페이지나 이미지 정보를 요청하고, 서버는 이 요청에 대한 정보를 응답하게 된다.
그런데 이때 누군가 네트워크에서 신호를 가로채면 내용이 노출되는 보안 문제가 발생할 수 있다. 이를 해결해주는 프로토콜이 바로 https
이다.
HTTPS(HyperText Tranfer Protocol over Secure Socket Layer)
https
는 정보를 암호화하는 SSL(Secure Socket Layer)*을 이용한 프로토콜이다. 여기에서 핵심은 보안 문제를 해결하기 위해 암호화 한다는 것인데, https
의 암호화에 대해 이해하기 위해서는 먼저 대칭키와 공개키에 대해 알아야한다.
* SSL(Secure Socket Layer) - 컴퓨터 네트워크에 통신 보안을 제공하기 위해 설계된 암호 규약으로 SSL는 과거의 명칭이고, 현재는 TLS(Transport Layer Security - 전송 계층 보안)라고 한다.
-
대칭키와 공개키
대칭키 암호화
란 암호화와 복호화 과정에서 같은 암호키(대칭키)를 사용하는 알고리즘 방식이다. 주고 받는 정보에 대해서 같은 암호키를 사용하기 때문에 빠르다는 장점이 있지만, 암호키가 노출되면 암호화된 내용을 해독 가능하기 때문에 보안 문제가 발생할 수 있다.공개키 암호화
란 암호키를 하나만 가지는 대칭키 암호화와 달리, 암호화와 복호화에 사용하는 암호키를 분리한 알고리즘 방식으로 비대칭키라고도 불린다. 암호키는 외부에 공개되며 암호화에 사용되는 공개키와 자신만이 가지며 복호화에 사용되는 개인키로 이루어져있다. 공개키 암호화의 진행 과정은 다음과 같다.- A가 ‘B의 공개키’로 암호화한 정보를 B에게 보낸다.
- B는 ‘자신의 개인키’로 정보를 복호화해서 확인한다.
- B는 다시 ‘A의 공개키’로 암호화한 정보를 A에게 보낸다.
- A는 ‘자신의 개인키’로 정보를 복호화해서 확인한다.
대칭키 암호화의 보안에 대한 단점을 보완하였다. 하지만 공개키 암호화방식에서는 더 복잡한 암호화와 복호화는 과정을 거치게 되는데, 매번 이 과정을 반복하게 되면 시간이 오래걸린다는 단점이 있다. 그래서 이 두 가지 방식을 혼합히여 사용할 수도 있다.
- A가 ‘B의 공개키’로 ‘대칭키’를 암호화해서 B에게 보낸다.
- B는 ‘자신의 개인키’로 이를 복호화해서 ‘대칭키’를 얻는다.
- B 는 ‘대칭키’로 정보를 암호화해서 A에게 보낸다.
- A는 ‘대칭키’로 정보를 복호화해서 확인한다.
- 앞으로 이 대칭키로 암호화와 복호화해서 정보를 주고 받는다.
이 방식은 SSL 암호화의 기본적인 과정으로
https
의 암호화에 사용되는 방식이다.
그럼 이제 https
가 통신하는 과정에 대해서 알아보자.
먼저, https
를 적용하기 위해서 공개키와 개인키를 만든다. 그 다음에 신뢰할 수 있는 CA*에 ‘내 서버의 공개키’를 맡긴다.
* ‘CA(Certificate Authority)’ - 공개키를 저장해주는 신뢰성이 검증된 민간 기업이다. CA로는 코모도 등이 있다.
CA에도 공개키와 개인키가 있다. CA는 CA의 이름과 ‘내 서버의 공개키’, 공개키의 암호화 방법 등의 정보를 담은 인증서를 만들고, 해당 인증서를 ‘CA의 개인키’로 암호화해서 내 서버에게 제공한다.
이제 내 서버에서는 클라이언트에서 첫 요청이 오면 이 암호화된 인증서를 준다. 클라이언트는 세계적으로 신뢰할 수 있는 ‘CA의 공개키’를 가지고 있다. CA 리스트에서 인증서에 적혀있는 이름과 같은 CA의 공개키를 찾아서 인증서를 해독하고 ‘내 서버의 공개키’를 얻는다.
이제 클라이언트는 ‘대칭키’를 만들어서 ‘내 서버의 공개키’를 사용해서 암호화하고, 서버로 보내게 된다. 그러면 서버에서는 ‘내 서버의 개인키’로 이를 복호화해서 ‘대칭키’를 얻는다. 이후에는 클라이언트와 서버가 통신할 때 이 대칭키를 사용해서 정보를 암호화하고 복호화해서 통신하게 된다.
이러한 과정을 통해 우리는 https
로 더 안전하게 정보를 주고 받을 수 있게 된다. 하지만 신뢰할 수 있는 CA가 아니라 자체적으로 인증서를 발급하거나, 신뢰할 수 없는 CA를 통해서 인증서를 발급받을 수도 있기 때문에 항상 안전한 것은 아니다. 이 경우에도 브라우저는 ‘주의 요함’, ‘이 사이트는 보안 연결(HTTPS)이 사용되지 않았습니다.’ 알림을 준다.
마무리
이번 시간에는 항상 당연하게 사용해왔지만, 잘 알지못했던 https
에 대해서 알아보았다. 혹시 나처럼 https
에 대해 잘 몰랐던 사람들에게 도움이 되었으먼 한다. 혹시 https
가 통신하는 과정에 대해서 조금 더 자세히 알고싶다면 참고 자료에 생활 코딩 블로그 글을 읽어보는 걸 추천한다.