What is Http?
웹 상에서 클라이언트가 서버에게, 서버가 클라이언트에게 정보를 전달하면서 통신하기 위해서 사용하는 대표적인 기술이 바로 Http 이다. Http 는 Hypertext Transfer Protocol 의 약어로, 우리말로는 하이퍼텍스트 전송 프로토콜 이라고 할 수 있다. 하이퍼텍스트는 HTML 과 같은 하이퍼미디어 문서를 나타내는 것으로, Http 는 이러한 하이퍼미디어 문서를 전송하기 위한 어플리케이션 계층의 프로토콜이라고 할 수 있다. Http 는 기본적으로 클라이언트(ex) 브라우저)가 서버에게 요청(Request)을 보내고 서버는 응답(Response)을 내려주는 전형적인 클라이언트-서버 구조를 지니고 있다. 또한 비연결성(클라이언트가 요청을 하고 요청에 대한 응답을 받으면 서버와의 연결을 끊어버리는 특성)과 무상태성(서버는 클라이언트의 상태를 저장하지 않음 → 비연결성으로부터 기인한 특성)의 특징을 지니고 있기 때문에, 다수의 클라이언트가 서버와 통신하기 쉽다는 장점을 가지고 있다.
What is Https?
Https는 Http에 보안 계층을 추가한 프로토콜이다.
HTTP는 암호화 없는 평문으로 데이터를 전송하기 때문에, 네트워크 중간에서 패킷을 가로채면 요청 내용이나 응답 내용을 그대로 확인할 수 있다는 치명적인 단점이 있다. 이 문제를 해결하기 위해 등장한 것이 Https이다. Https는 데이터를 암호화하여 전송함으로써 도청, 변조, 위조와 같은 보안 문제를 해결한다. 즉, Https는 클라이언트와 서버 사이의 통신 내용을 암호화하고, 통신 상대가 신뢰할 수 있는 대상임을 검증하는 역할을 한다. 이러한 Https 에서 암/복호화와 같은 보안 기능을 담당하는 핵심 기술이 바로 TLS/SSL 이다.
TLS/SSL
SSL 은 초기 암호화 통신 프로토콜로 웹 브라우저와 서버 간의 데이터를 암호화하기 위해 개발되어 오랜 시간 사용해왔으나, 여러 보안 취약점이 발견되어 현재는 더이상 사용되지 않으며 해당 보안 기술은 TLS 로 대체되었다. 따라서 구버전의 프로토콜이 아닌 이상 SSL 을 더이상 채택하지는 않지만, 이를 개선한 TLS 인증서 등도 SSL 을 대체하는 위치이기 때문에 관례상 SSL 인증서 등으로 표현하는 일이 적지않다. 오늘날 일반적으로 "SSL인증서" 라고 하는 것은 기술적으로는 대부분 TLS 인증서인 경우가 많다.
Https 가 어플리케이션 계층인 Http에 보안 기능을 추가한 것이라고 해서 어플리케이션 계층에 보안 계층이 추가되는 방식이 아니라, 전송 계층(Transport Layer) 에 보안 계층을 추가하는 것이다.(TLS → Transport Layer Security)
이 기술을 구현하기 위해서 웹 서버에 설치하는 것이 SSL/TLS 인증서이다. SSL/TLS 인증서에는 다음과 같은 보안 기술들이 탑재되어 있다.
- 데이터 암/복호화
- 통신 대상을 서로 확인하는 신분 확인(authentication)
- 믿을 수 있는 인증서를 위한 디지털 서명(digital signiture)
- 디지털 서명을 해주는 인증 기관(CA: Certificate Authority)
- 공개키를 안전하게 전달하고 공유하기 위한 프로토콜
- 암호화된 메세지의 변조 여부를 확인하는 메시지 무결성 알고리즘
TLS/SSL 인증서의 핵심은 암/복호화이다. 평문을 암호화하고 복호화 하는 데는 대표적으로 대칭키 암호화 방식, 비대칭키 암호화 방식이 있다.
대칭 키 암호화 방식
대칭키 암호화 방식은 암호화와 복호화에 같은 키를 사용하는 방식이다. 즉, 데이터를 암호화할 때 사용한 키와, 그 데이터를 다시 원래대로 복호화할 때 사용하는 키가 동일하다. 이 방식의 가장 큰 특징은 속도가 매우 빠르다는 점이다. 암호화·복호화 과정이 단순하기 때문에 대용량 데이터를 처리하는 데 매우 효율적이다. 그래서 실제 서비스 환경에서는 대칭키 암호화가 거의 필수적으로 사용된다. 그러나 키를 중간에 탈취당한 경우, 탈취자는 암호화된 모든 데이터를 그대로 복호화할 수 있게 되기 때문에 보안상 명확한 취약점이 존재한다. 따라서 실제 시스템에서는 대칭키 암호화 방식과 비대칭키 암호화 방식을 적절히 혼합하여 사용한다.
비대칭 키 암호화 방식(공개 키 암호화 방식)
비대칭키 암호화 방식은 서로 다른 두 개의 키(개인 키/공개 키)를 사용하는 암호화 방식이다. 이 두 키는 쌍(pair)으로 존재하며, 공개키로 암호화한 데이터는 반드시 개인키로만 복호화할 수 있다. pair 가 아닌 다른 키로 복호화하는 것은 불가능하다.
공개키는 말 그대로 누구에게나 공개할 수 있는 키이다. 따라서 공개키 암호화 방식은 사전에 안전하게 서로의 공개키를 나누어 받는 과정이 필요한데, 이 때 사용하는 대표적인 알고리즘으로 RSA(Rivest - Shamir - Adleman) 와 디피-할만 알고리즘이 있다.
언뜻 보면 암/복호화에 사용하는 키를 공개적으로 나누어 갖는다는 것이 보안에 취약해 보일지도 모르지만, 복호화는 개인키로만 가능하기 때문에 개인키의 철저한 관리만 갖춰진다면 대칭 키 암호화 방식보다 훨씬 뛰어난 안정성을 가진다. 그러나 연산 과정이 복잡하고 컴퓨터 리소스를 많이 사용하기 때문에, 실제 시스템에서는 대칭 키 암호화 방식과 혼합하여 사용한다.
TLS/SSL Handshake
TLS/SSL Handshake 는 위와 같은 암/복호화, 신분확인 등을 위해 브라우저와 서버 간 보안 연결을 수립하는 절차이다. 간략한 절차는 다음과 같다.
- Client Hello - 클라이언트가 서버에 접속하면서 지원 가능한 TLS 버전과 암호화 알고리즘 목록을 보낸다.
- Server Hello
- 서버가 사용할 TLS/SSL 버전과 암호화 알고리즘을 선택해서 응답한다.
- 이때 서버는 서버 인증서(공개키 포함 - CA 의 비밀키로 암호화되어 발급된 상태)를 함께 전달한다. - 서버 인증
- 클라이언트는 서버 인증서를 검증한다.
- 인증서가 신뢰된 CA(Certificate Authority)에 의해 서명되었는지 확인한다.
- 브라우저에 내장된 CA 공개키(브라우저에서는 대부분 CA에서 제공한 공개 키를 가지고 있다)로 인증서를 복호화하는데 성공한다면 CA 발급이 증명된 셈 - 대칭키 생성 및 전달
- 클라이언트는 임의의 대칭키(세션 키)를 생성한다.
- 이 대칭키를 서버의 공개키로 암호화해서 서버에 전달한다. - Handshke 완료
- 서버는 자신의 개인키로 대칭키를 복호화한다.
- 이후부터는 이 대칭키를 사용해 빠른 대칭키 암호화 통신을 수행한다.
TLS/SSL Handshake의 핵심 아이디어는 처음 보안 연결을 수립할 때는 안전한 키 교환을 위해 공개키를 사용하고, 이후에는 빠른 통신을 위해 대칭키를 사용한다는 것으로, 각 암호화 방식의 장점만 취해 적절히 결합한 구조이다. 이 방식을 통해 우리는 Https 프로토콜 상에서 빠르고도 안전하게 통신할 수 있다.
