HTTPS
보안상 문제가 발생하는 HTTP
HTTP에는 많은 장점들이 있지만 아래와 같은 보안상 문제가 발생할 수 있기 때문에 현대 웹에서는 HTTPS를 통해 해결하고 있다.
평문 통신(메시지 탈취 가능)
TCP/IP 특성상 중간에 누군가가 패킷을 가로채면 내용을 확인할 수 있으며, HTTP는 암호화가 되어 있지 않기 때문에 패킷을 가로채면 내용을 확인할 수 있다. 이를 해결하기 위해 암호화를 사용하는 방법이 있다.
통신 암호화
통신을 암호화 하는 방법으로 SSL(Secure Socket Layer)와 TLS(Transport Layer Security)를 사용해 암호화를 할 수 있다.
컨텐츠 암호화
통신을 통해 전달하고 있는 메시지를 암호화 하는 방법으로, 암호화된 메시지를 전달하고 받는다. 클라이언트/서버 모두 암호화/복호화 과정을 거쳐야 하기 때문에 암호화/복호화 과정이 추가되어 성능이 떨어지는 단점이 있으며, 주로 웹 서비스에서 사용할 수 있다.
통신 상대 확인 불가능(위장 가능)
HTTP는 클라이언트가 서버에게 요청을 보낼 때, 서버가 해당 클라이언트가 맞는지 확인하지 않기 때문에 위장이 가능하다. 이를 해결하기 위해 제 3자가 발급하는 인증서를 사용해 서로를 확인하여 위장을 방지할 수 있다.(현재 위조하는 것은 기술적으로 어렵다.)
완전성 확인 불가능(변조 가능)
HTTP는 메시지가 중간에 변조되지 않았는지 확인할 수 없기 때문에 변조가 가능하다.(요청이나 응답을 가로채서 변조하는 공격 = 중간자 공격)
이를 방지하기 위한 방법이 디지털 서명이라는 방법이 존재하나, 이 방법 하나만으로는 완벽한 보안을 보장할 수 없다.
HTTP + SSL = HTTPS
HTTP에 SSL 혹은 TLS를 적용한 것으로, HTTP에 SSL이나 TLS를 적용하면 위에서 언급 된 보안상 발생하는 문제를 해결할 수 있다. 새로운 애플리케이션 계층의 프로토콜은 아니며, HTTP 통신 소켓 부분을 SSL이나 TLS로 대체한 것이다.
SSL(Secure Socket Layer) : 1994년에 공개된 암호화 프로토콜
TLS(Transport Layer Security) : SSL의 후속 버전으로 현재 주로 사용되는 프로토콜
TLS와 SSL는 매우 비슷하기 때문에 SSL이라고 통칭하여 사용하는 경우가 많다.
HTTP - 애플리케이션 계층
HTTP - 애플리케이션 계층
-
SSL or TLS - 보안 계층
TCP - 전송 계층
TCP - 전송 계층
IP - 네트워크 계층
IP - 네트워크 계층
네트워크 인터페이스 - 데이터 링크 계층
네트워크 인터페이스 - 데이터 링크 계층
인코딩 및 디코딩 작업은 대부분 SSL 라이브러리 내부에서 처리되기 때문에, 웹 클라이언트나 서버가 별도로 크게 처리할 부분은 없다. 결국 HTTPS는 HTTP 프로토콜에 대칭/비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한 것으로 네트워크 상에서 가장 널리 사용되는 보안 프로토콜이다.
HTTP / HTTPS 트랜잭션 비교
URL 프로토콜 스키마에 따라 HTTP/HTTPS로 통신하게 되며, 각각 아래와 같은 트랜잭션을 거치게 된다.
서버의 80포트로 TCP 커넥션 수립
서버의 443포트로 TCP 커넥션 수립
-
SSL 보안 매개변수 핸드셰이크
TCP를 통해 보내진 HTTP 요청
SSL을 통해 보내진 HTTP 요청 / TCP를 통해 보내진 암호화된 요청
TCP를 통해 보내진 HTTP 응답
SSL을 통해 보내진 HTTP 응답 / TCP를 통해 보내진 암호화된 응답
-
SSL 닫힘 통지
TCP 커넥션 닫힘
TCP 커넥션 닫힘
SSL Handshake
암호화된 HTTP 메시지를 보내기 위해서는 클라이언트와 서버가 서로 암호화에 필요한 정보를 교환해야하는데, 이를 SSL Handshake라고 한다. 서버-클라이언트 최초 연결 시 비대칭키 암호화 방식(최초 연결)을 사용하여 서로의 신원을 확인한 뒤 세션 키를 생성하고, 그 이후에는 생성 된 세션 키를 통해 대칭키 암호화 방식을 사용하여 데이터를 주고받는다.
클라이언트 헬로 (Client Hello)
클라이언트는 서버에 “Client Hello” 메시지를 보내어 통신을 시작
클라이언트가 사용 가능한 암호화 알고리즘 전송
서버 헬로 (Server Hello)
서버는 클라이언트의 헬로 메시지에 응답하여 “Server Hello” 메시지 전송
서버가 선택한 알고리즘을 전송
인증 (Certificate)
서버는 SSL 디지털 인증서를 클라이언트에게 전송(해당 인증서는 서버의 신원을 확인하는 데 사용)
클라이언트는 서버가 보낸 CA(Certificate Authority, 인증 기관)의 개인키로 암호화된 SSL 인증서를 공개된 CA의 공개키를 사용하여 복호화
또한 클라이언트는 데이터 암호화에 사용할 대칭키(비밀키)를 생성한 후 SSL 인증서 내부에 들어있던 서버가 발행한 공개키를 이용해 암호화하여 서버에게 전송
서버 키 교환 (Server Key Exchange)
서버의 공개키가 SSL 내부에 없었을 경우 서버가 직접 전달하는 과정
이미 SSL 내부에 있었다면 생략
Server Hello Done
핸드쉐이크 초기 단계 완료
클라이언트 키 교환 (Client Key Exchange)
클라이언트는 세션 키를 생성하기 위한 정보를 서버에 보냅니다. 이는 서버의 공개 키를 사용하여 암호화되어 전송됩니다.
실제로 데이터를 암호화할 대칭키를 클라이언트가 생성하여 SSL 인증서 내부에서 추출한 서버의 공개키를 이용해 암호화한 후 서버에게 전달
Client ChangeChipherSpec / Finished
클라이언트에서 “ChangeChipherSpec” 메시지를 보내 암호화된 통신 시작을 알림
이후 “Finished” 메시지를 보내 핸드쉐이크 과정 완료 알림
Server ChangeChipherSpec / Finished
서버도 “ChangeChipherSpec” 메시지를 보내 암호화된 통신을 시작함을 알림
이후 “Finished” 메시지를 보내 핸드쉐이크 과정 완료 알림
사이트 인증서 검사
SSL 자체는 사용자에게 인증서 검증 요구를 하지 않지만, 최신 웹브라우저 대부분이 인증서에 대해 기본적인 검사를 한 뒤 높은 수준의 검사를 하는 방법을 사용자에게 제공한다. 넷스케이프에서는 웹 서버 인증서 검사를 위한 알고리즘을 만들어 기초를 구축했으며, 수행 단계에서 아래의 검사를 수행한다.
날짜 검사: 인증서의 시작 및 종료일 검사
서명자 신뢰도 검사: 브라우저에 내장된 인증서 발급자 목록과 인증서 발급자의 이름을 비교(신뢰할 수 있는 발급자인지 검사)
서명 검사: 서명기관의 공개키를 서명에 적용하여 체크섬과 비교하여 무결성 검사
사이트 신원 검사: 인증서 복사 혹은 트래픽 중간자 공격을 막기 위해 인증서의 도메인 이름과 통신 중인 서버 호스트의 도메인이 일치하는지 검사
참고자료
Last updated
Was this helpful?