Network - SSL , HTTPS, CA 개념 (SSL인증서)
ssl개념에대해서 알아보도록 하겠습니다.
1. SSL
SSL(secure socket layer)은 네트워크에서 메시지 전송시 보안을 위해 개발된 표준 프로토콜입니다. 즉, HTTP만을 위한 프로토콜이 아닌 응용계층의 여러 프로토콜의 보안을 위해 발명된 프로토콜입니다. 조금 더 정확히 말씀드리자면, TCP를 보호하는 프로토콜입니다.
클라이언트 또는 서버에서 메시지를 만들어 상대에게 전달할때, 응용계층에서 만들어진 메시지가 전송계층으로 가기전 SSL을 통해 데이터가 암호화가 됩니다. 그 후 전송계층을 통해 네트워크로 데이터가 상대에게 전달이 됩니다.
1.1 SSL 장점
SSL은 3가지의 장점을 제공합니다.
- 기밀성(암호화)
- 데이터 무결성
- 서버인증
1.2 SSL없을시의 문제점
간단한 전자상거래 시나리오를 통해 위의 사항들이 고려되지 않는 경우의 문제점을 알아보도록 하겠습니다.
A는 인터넷 쇼핑을 진행하며 마음에 드는 옷을 발견하여, 사이트에 옷과 수량, 자신의 주소, 지불카드 정보를 제공합니다. 이때 앞서 살펴본 SSL의 장점이 없을때의 문제점을 살펴보도록 하겠습니다.
기밀성(암호화)
기밀성이 제공되지 않는다면, A의 카드번호가 유출되어, 타인이 A의 카드로 결제를 진행할 수 있습니다.
데이터 무결성
데이터 무결성이 제공되지 않는다면, 침입자가 A의 거래정보를 수정하여 옷의 수량을 변경하여 원치않는 양의 옷을 받게 될 수 있습니다.
서버인증
서버인증을 제공하지 않는다면, 가짜 사이트에 결제를하게되어 A의 돈만을 받고 물건을 배송하지 않을 수 있습니다.
2. 헷갈릴 수 있는 개념들
2.1 HTTP와 HTTPS
HTTP는 다들 아시다시피 HyperText 문서를 클라이언트와 서버간 송수신 하기위한 프로토콜입니다. HTTPS는 직역하자면, HTTP + SSL(Secure Socket Layer)을 합친말로, 보다 보안이 강화된 HTTP 프로토콜이라는 의미입니다.
왜?
HTTP의 경우 보안적인 측면을 고려하고 만들어진 프로토콜이 아니기 때문에, 오가는 패킷을 중간에서 가로채어 확인하는 것이 매우 쉽습니다. 따라서 SSL은 이를 보완하기위해 등장했습니다.
2.2 SSL과 TLS
결론부터 말씀드리면 SSL과 TLS는 같은말입니다. 넷스케이프사에서 SSL을 발명했고 점차 사용자들이 많아지면서 표준화 기구인 IETF가 관리하며 TLS로 이름이 바뀌었습니다.
3. 암호화 방식
SSL의 동작방식을 이해 하기 위해서는 아래의 암호화 방식을 이해해야합니다.
3.1 대칭키
대칭키 방식은 아주 간단합니다. 두 명의 사용자가 있을때 둘 모두가 같은 암호키를 가지고 대화를 하는 방식입니다. 때문에 알고리즘이 상대적으로 간단하며 동작이 빠릅니다.
3.2 공개키
공개키는 대칭키 방식의 단점인 두 사용자가 모두 같은 비밀번호를 알아야한다는 단점을 보완하고자 고안된 방법입니다. 두사용자가 모두 같은 키를 사용하기 위해서는 한 사용자가 생성한 키를 상대방에게 전달해야하는데 이때 암호키가 유출될 수 있기 때문입니다.
공개키 방식은, 2개의 키를 가지고 암호화를 진행하게됩니다. 한 키는 공개가 되어있으며(공개키), 나머지 하나는 키의 주인만이 알 수 있습니다.(개인키)
우선, 메시지를 전달하고자 하는 대상의 공개키로 내가 전달할 메시지를 암호화합니다. 그렇다면 전달받은 상대방은 자신의 개인키를 이용하여 메시지를 복호화하면 끝입니다. 너무 간단히 설명드렸지만 이밖에 더아셔야 할 내용이 있으므로 검색을 통해 더자세히 공부하시길 권고드립니다.
전자서명
4. SSL 인증서
SSL인증서는 서버가 정말 그서버가 맞는지를 확인할 수 있도록 도와주는 수단입니다. 서버가 진짜 서버인지를 확인한다는게 무슨말인지 아래 시나리오를 통해 알아보도록 하겠습니다.
4.1 SSL 인증서의 필요성
가짜 사이트(서버) 시나리오
사용자 A는 햄버거 주문을 위해 롯데리X 사이트에 접속하여 주문을 합니다. 이때 경쟁사인 맥도날X에서 이 요청을 염탐하고 있다가 가로채어 주문을 받았다는 알림을 대신 보냅니다. 그후 배달은 하지 않습니다. 롯데리X에서는 주문을 하루종일 받지 못하게 됩니다.
공개키를 이용한 가짜 사이트(서버) 시나리오
어떻게 이런일이 가능할까요? 공개키 암호화방식을 이용하면 되지 않을까요? 예를 들어 사이트에서 자신의 공개키를 사용자에게 전달하고, 사용자가 이 공개키를 이용하여 메시지를 암호화하여 보낸다면 진짜 사이트에서만 주문을 받는게 가능하지 않을까요?
공개키를 이용했다고 가정하고 다시 시나리오를 살펴보겠습니다.
사용자 A가 롯데리X 사이트에 접속합니다. 이때, 공개키 방식의 단점을 알고 있는 맥도날X 주인이 롯데리X와 아주 유사한 사이트를 만들어 마치 롯데리X사이트 인 것처럼 위장합니다. 그 후 사용자 A에게 가짜 롯데리X 공개키를 전달합니다. 사용자 A는 가짜 사이트의 공개키를 가지고 주문메시지를 암호화하고, 전달합니다.
이 처럼 공개키를 이용해 암호화를 하더라도 진짜 사이트인지를 증명할 수단이 필요합니다. 이때문에 제3자가 해당 사이트가 진짜 인지를 대신증명해주는 것입니다. 이를 통해 사용자는 자신이 통신하는 사이트가 진짜 사이트인지를 믿을 수 있게 됩니다.
4.2 SSL이 제공하는 기능
CA
SSL 인증서를 발급하는 기관으로, 신뢰할 수 있는 기관들을 의미합니다.
4.3 SSL 통신과정
SSL 인증서가 의도한 서비스임을 보장하는 방법
1. 브라우저는 이미 CA기관 리스트를 알고있습니다.
2. 브라우저를 통해 사용자가 웹 서비스에 접근합니다.
3. 웹서비스는 CA기관을 통해 발급받은 SSL인증서(인증기관의 비밀키로 암호화 되어있다.)를 사용자에게 전달합니다.
4. 브라우저는 SSL인증서가 CA리스트에 포함되어있는지를 확인합니다.
5. 포함되어 있다면, 브라우저는 해당 SSL인증서에 대응하는 CA리스트에 존재하는 공개키를 이용해 SSL인증서를 복호화 합니다. => 공개키로 복호화에 성공한다면, 이에 대응되는 비밀키로 암호화가 되었다는 의미이므로, SSL인증서에 해당하는 서비스의 응답임을 확신할 수 있습니다. 즉, 신뢰할 수 있는 서버임을 알 수 있습니다.(모르시겠다면, 전자서명을 검색하여 공부하세요.)
HTTPS의 SSL 통신 방법
대칭키 주고받기
1. 클라이언트(브라우저쪽)은 특정 방법을 통해 "premaster secret"이라는 키를 생성합니다. 이 키는 데이터 통신시 대칭키 암호화에 사용될 session key를 만들때 사용되므로 중간에 공격자에 의해 노출되어서는 안됩니다. => 이 때문에, 서버의 공개키를 이용해 "premaster secret"을 암호화하여 서버에 전달합니다.
2. 서버는 클라이언트로부터 전달받은 "암호화된 premaster secret"키를 자신의 비공캐키를 이용하여 복호화합니다.
3. 서버와 클라이언트는 모두 premaster secret을 가지게 되었습니다. 이제 서버와 클라이언트는 모두 premaster secret을 일련의 과정을 거쳐서 session key로 만듭니다.
4. 서버와 클라이언트는 session key를 이용해 대칭키 암호화하여 데이터를 주고받습니다.
비공개키와 대칭키 암호화 방식을 같이 사용하는 이유
- 공개키를 이용한 통신 방식은 이를 복호화 암호화 하는데 컴퓨팅 파워를 많이 소모하기 때문에 효율적이지 못합니다.
- 성능상 이점이있지만, 처음 키를 주고받을 때, 키가 누출될 염려가 있습니다. 즉 키를 주고받기 위한 방식이 필요합니다.