웹 어플리케이션을 개발하고, 운영을 하다보면, 항상 보안 문제에 부딪치게 된다.
XSS 취약점, CSRF 취약점 등 OWASP TOP 10에 포함되어 있는 여러 이슈들이 많지만,
이번 포스팅에는 HTTPS에 대해서 간단히 정리해보려고 한다.
HTTPS
HyperText Transfer Protocol over Secure Socket Layer
HTTPS는 독립된 프로토콜이 아닌, 말 그대로 SSL위에서 동작하는 HTTP이다.
HTTPS를 알기 위해서는 먼저, HTTP와 SSL에 대해서 이해 해야한다.
HTTP
HyperText Transfer Protocol
텍스트 기반의 통신규약으로 인터넷에서 데이터를 주고 받는 프로토콜
HTTP 메시지는 HTTP 서버와 HTTP 클라이언트에 의해 해석이 된다.
TCP/ IP를 이용하는 응용 프로토콜이다.
HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜이다.
HTTP는 연결을 유지하지 않는 프로토콜이기 때문에 요청/응답 방식으로 동작한다.
Plain Text
복사
HTTP, HTTPS 통신간 패킷 비교
클라이언트와 서버간의 패킷을 분석할 수 있는 WireShark를 통하여
HTTP 통신과 HTTPS통신시 패킷을 비교하면 아래와 같다.
•
보라색 부분이 HTTPS 통신 패킷, 연두색 부분이 HTTP 통신 패킷
•
각 통신에서 Application Data가 들어 있는 패킷을 열어보았다. (빨간 밑줄 친 패킷)
•
위가 HTTPS 패킷(198163), 아래가 HTTP 패킷(198787)
•
HTTPS 패킷에서는 전송 내용을 평문으로 확인할 수 없도록 암호화되어있는 반면에,
HTTP 패킷에서는 값이 평문으로 그대로 노출되는 것을 확인할 수 있다.
•
위 그림을 통해 확인할 수 있듯이, HTTP 전송의 경우 데이터 자체를 암호화 하지 않으면
패킷 도청으로 데이터 유출이 가능하다.
여기서 알고 넘어가자!
•
브라우저 개발자 도구에서 확인할 수 있는 Request 정보는 패킷의 정보가 아니다. 평문으로 보여지는 것이 당연함!
•
웹 디버그 툴 Fiddler를 통한 관찰에서는 HTTPS 통신의 데이터를 평문으로 확인할 수 가 있는데,
이는 Fiddler에서 SSL 복호화를 위해 동적으로 조작 인증서를 생성하는 과정을 거치기 때문이다.
(Fiddler에서 HTTPS 패킷을 확인하기 위해 아마 조작된 Root 인증서 설치과정을 미리 거쳤을 것이다.)
•
각 Wireshark와 Fiddler의 패킷정보는 다른 방식으로 가져온 패킷 정보이다.
(순수 통신 패킷은 NIC에 들어오는 패킷을 캡쳐하는 Wireshark가 맞음)
SSL
Secure Socket Layer
•
Netscape에서 서버와 브라우저 간 보안을 위해 만든 프로토콜
•
SSL은 CA(Certificate Authority)라 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용한다.
또한 SSL을 사용한 HTTP 암호화 통신 (HTTPS) 을 사용하기 위해선 SSL 인증서가 필요하다.
CA (인증기관)
Certificate Authority
SSL 인증서의 역할은 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 보장하는 역할을 한다.
이 역할을 하는 민간기업들이 있는데 이런 기업들을 CA(Certificate authority) 혹은 Root Certificate 라고 부른다.
CA는 아무 기업이나 할 수 있는 것이 아니고 신뢰성이 엄격하게 공인된 기업들만이 참여할 수 있다.
그 중에 대표적인 기업들은 아래와 같다. 수치는 현시점의 시장점유율이다. (위키피디아 참조)
•
Comodo with 26%
•
GoDaddy with 14%
•
GlobalSign with 7.7%
SSL을 통해서 암호화된 통신을 제공하려는 서비스는 CA를 통해서 인증서를 구입해야 한다.
CA는 서비스의 신뢰성을 다양한 방법으로 평가하게 된다.
물론 무료로 인증서를 제공하는 기업도 있다. ex: Let's Encrypt
범용 브라우저 및 OS에서는 Trusted CA List (신뢰하는 인증기관 리스트)를 가지고 있다.
SSL Certification (SSL 인증서)
Secure Socket Layer Certification
클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 보장 및
데이터 암/복호화에 필요한 알고리즘, 공개키 등을 제공
그러면 인증서에 어떤 정보가...?
SSL 인증서를 사용한 데이터 암호화 동작 원리
먼저, 대칭 키 & 공개 키 암호화가 뭔지 알고 갑시다!
대칭키 암호화
•
하나의 비밀키를 양쪽(client & server)가 모두 같이 사용
•
암호화와 복호화에 사용하는 키가 같은 암호화 알고리즘
•
공개키와 비밀키를 별도로 가지는 것과 구별되는데, 이와 비교하면 계산속도가 빠르다는 장점
•
비밀키 하나만 알아내면 암호화된 내용을 해독 가능 → 해커로부터 안전 X
•
대표적인 대칭키 알고리즘을 사용하는 암호화 방식으로는 아래와 같다.
DES, 3-DES, AES, SEED, ARIA, MASK 등...
공개키 암호화
•
비밀키 하나만 가지는 대칭키 암호 방법과 달리, 공개키와 비밀키 두 개가 존재
•
공개키 암호를 구성하는 알고리즘을 대칭키 암호 방식과 비교하여 비대칭 암호라고 불림
•
암호화와 복호화에 사용하는 키가 서로 다름
•
암호화할 때의 키는 공개키(public key), 복호화할 때의 키는 개인키(private key)
•
공개키는 누구나 알 수 있지만, 그에 대응하는 비밀키는 키의 소유자만이 알 수 있어서
특정한 비밀키를 가지는 사용자만이 내용을 열어볼 수 있도록 하는 방식
SSL 통신과정
STEP 1 # from Client to Server
•
클라이언트는 랜덤 데이터 및 사용 가능한 암호화 알고리즘 목록 서버로 전달.
STEP 2 # from Server to Client
•
서버는 랜덤 데이터, 선택한 암호화 알고리즘 및 SSL 인증서를 클라이언트로 전달.
STEP 3 # from Client to Server
•
전달 받은 인증서의 유효성 검증 및 클라이언트와 서버가 생성한 랜덤 데이터를 조합 하여,
pre master secret를 생성하고, 이 값을 인증서의 공개키로 암호화하여 서버로 전달.
클라이언트는 암호화 하기 전, pre master secret을 master secret으로 저장 후,
master secret를 key로 사용하여 session key를 생성한다.
STEP 4 # from Server to Client
•
클라이언트로부터 전달 받은 암호화 된 pre master secret를 서버에서 가지고 있는
개인키로 복호화 한 후, master secret 으로 저장하다.
이를 key로 사용하여 session key를 생성한다.
이로써 클라이언트와 서버는 동일한 session key를 가지게 되었고,
session key는 송/수신 데이터에 대한 암/복호화에 사용되는 키가 된다.
즉, 이 때 부터 클라이언트와 서버는 동일한 키로 암/복호화하는 대칭키 알고리즘을 사용한다.
클라이언트와 서버의 세션이 종료되는 순간, session key는 폐기가 된다.
요약하자면, 세션이 수립될 때, 양측은 공개키 방식으로 마스터키를 생성 후,
세션간 양측은 동일한 마스터키로 대칭키 방식으로 데이터를 암호화 하여 통신한다.
“이제 SSL이 뭔지는 알겠어. 근데 요즘은 SSL말고, TLS 통신 어쩌구 하는데.. TLS는 뭐지?”
TLS
Transport Layer Security
SSL을 기반한 기술이며, 국제 인터넷 표준화 기구에서 표준으로 인정 받은 프로토콜이다.
SSL과 TLS은 다른 프로토콜이 아니고, 본질적으로 같으며, TLS는 SSL의 최신 버전으로 보면 된다.
SSL의 역사
최초 제안 : 넷스케이프사
버젼 : SSL v1.0 (1994.7), SSL v2.0 (1994.12), SSL v3.0 (1996.11)
SSL v3.0은 그 당시 사실상의 웹 보안 표준이었음
Plain Text
복사
TLS의 역사
SSL v3.0 을 참고로하여 RFC 2246(1999년)으로 표준화된 것이 TLS임
버젼 : TLS 1.0 (RFC 2246,1999) : SSL v3.1에 해당,
TLS 1.1 (RFC 4346, 2006), TLS 1.2 (RFC 5246, 2008), TLS 1.3 (RFC 8446, 2018)
Plain Text
복사
참고로 SSL의 최신 버전인 SSL v3.0은 2015년에 POODLE, DROWN 등의 취약점이 발견되어
암호화 프로토콜로서의 기능을 잃은 상태이다. 이하 버전도 마찬가지이다.
이 쯤에서 다시 HTTPS가 무엇인지 상기해보자.
HTTPS
Hyper Text Transfer Protocol Over Secure Socket Layer
HTTPS는 독립된 프로토콜이 아닌, 말 그대로 SSL위에서 동작하는 HTTP이다.
즉, HTTPS는 독립된 프로토콜이 아니며, HTTP 통신을 할 때의 Socket 부분을 SSL이나 TLS 프로토콜로 대체하는 것!
PS. 이 글을 보신분께서는 주위에서 HTTPS, SSL, TLS라는 단어가 나왔을 때,
약간의 TMI를 말할 수 있는 변태 엔지니어가 되었으면 한다.