[네트워크] HTTPS, 보안 기능의 껍질을 덮어쓴 HTTP

Woonil·2025년 2월 25일

보안

목록 보기

2/2

HTTPS(HyperText Transfer Protocol Secure)는 새로운 애플리케이션 계층의 프로토콜이 아닌, HTTP 통신하는 소켓 부분을 SSL(Secure Socket Layer)/ TLS(Transport Layer Security)라는 프로토콜로 대체한 것이다.

HTTPS = HTTP + SSL(Secure Sockets Layer) or TLS

HTTP protocol의 암호화된 버전(클라이언트와 서버 간의 모든 커뮤니케이션을 암호화 하기 위해 SSL이나 TLS를 사용)으로 클라이언트가 민감한 정보를 서버와 안전하게 주고받도록 해준다.

장점
- 사용자가 사이트에 보내는 정보들을 제 3자가 못 보게 한다.
- 접속한 사이트가 믿을 만한 곳인지를 알려준다.

🤔개념

왜 HTTPS를 사용하게 되었는가?

HTTP의 문제점

HTTP와 같이 암호화하지 않은 프로토콜의 문제점은 다음과 같다.

데이터 기밀성: HTTP 는 평문 통신이기 때문에 도청이 가능

평문

암호 알고리즘의 입력 대상으로, 암호화되지 않은 정보

TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있기에 패킷을 수집하는 것만으로 도청할 수 있다. 평문으로 통신을 할 경우 메시지의 의미를 파악할 수 있기 때문에 암호화하여 통신할 필요가 생겼다. ⇒ 통신 자체를 암호화 : SSL(Secure Socket Layer) or TLS(Transport Layer Security) 라는 서로 다른 프로토콜을 조합함으로써 HTTP 의 통신 내용을 암호화할 수 있다. ⇒ 콘텐츠를 암호화 : ****HTTP 메시지에 포함되는 콘텐츠만 암호화하며, 받은 측에서는 그 암호를 해독하여 출력하는 처리가 필요하다.
통신 상대 인증: 통신 상대를 확인하지 않기 때문에 위장이 가능 HTTP 에 의한 통신에는 상대가 누구인지 확인하는 처리는 없기 때문에 누구든지 request를 보낼 수 있다. IP 주소나 포트 등에서 그 웹 서버에 액세스 제한이 없는 경우 request가 오면 상대가 누구든지 무언가의 response를 반환한다.
- 문제점
  - request를 보낸 곳의 웹 서버가 원래 의도한 response를 보내야 하는 웹 서버인지 확인할 수 없다.
  - response를 반환한 곳의 클라이언트가 원래 의도한 request를 보낸 클라이언트인지를 확인할 수 없다.
  - 통신하고 있는 상대가 접근이 허가된 상대인지를 확인할 수 없다.
  - 어디에서 누가 request 했는지 확인할 수 없다.
  - 의미없는 request도 수신하므로, DoS 공격을 방지할 수 없다.
    
    ⇒ SSL or TLS는 상대를 확인하는 수단으로 증명서를 제공한다. 이는 제 3자 기관(CA)에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다. 이 증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자의 개인 정보 누설 등의 위험성이 줄어들게 된다. 또한 클라이언트는 이 증명서로 본인 확인을 하고 웹 사이트 인증에서도 이용할 수 있다.
데이터 완전성: 완전성을 증명할 수 없기 때문에 변조가 가능 완전성(정보의 정확성)을 증명할 수 없다. 즉, 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치하는 것을 보장할 수 없다. 중간자 공격이 일어나 request나 response의 내용이 변조되더라도 이 사실을 알 수 없다.

중간자 공격(Man-in-the-Middle)

공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격

⇒ MD5, SHA-1 등의 해시값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만, 확실히 확인할 수 있는 것은 아니므로 인증이나 암호화, 그리고 다이제스트 기능을 제공하는 HTTPS를 사용해야 안전하다.

HTTPS는 왜 안전한가?

SSL(Secure Socket Layer)

HTTP는 원래 TCP와 직접 통신했지만, HTTPS에서 HTTP는 SSL 과 통신하고 SSL이 TCP 와 통신하게 된다. SSL을 사용한 HTTPS는 암호화와 증명서, 안전성 보호를 이용할 수 있다. 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다.

하이브리드 암호 시스템

공통키를 공개키 암호화 방식으로 교환한 다음에, 다음부터의 통신은 공통키 암호를 사용하는 방식

공개키가 가짜라면?

CA(Certificate Authority)

그렇다면 서로에게 공유되는 공개키가 진짜인지는 어떻게 확인할까? 사실 이를 증명할 방법은 없다. 대신 이 증명을 대신해주는 공인된 제 3자가 존재한다면 나름 그럴듯 해진다. 이 제 3자의 역할을 하는 것이 CA이며, 이는 서버가 보낸 공개키가 정품인지 인증해주는 공인된 민간기업이다. 브라우저의 프로그램에 CA의 목록이 내장되어 있다.

서버의 CA 등록 과정
1. 서버는 인증 기관에 서버의 공개키와 사이트 정보를 전송한다.
2. 인증 기관은 사이트 검증 후, 인증 기관의 개인키로 서명한다. (디지털 서명)
3. 인증 기관은 사이트 인증서(SSL 인증서)를 서버에게 전송한다.

HTTPS 통신 과정

handshake: 서버와 클라이언트 간 탐색과정
클라이언트가 랜덤 데이터를 서버로 보낸다.
서버는 서버의 인증서와 랜덤 데이터를 클라이언트로 보낸다.
클라이언트는 두 랜덤 데이터를 혼합하여 임시키를 생성한다. (임시키는 서버에 공개키로 보내진 후 일련의 과정을 통해 양쪽에 동일한 대칭키 생성)
클라이언트는 인증서의 진가 여부를 브라우저에 내장된 CA(Certificate Authority)의 정보를 통해 확인한다. (비대칭키 사용: 인증서는 CA의 개인키로 암호화 돼있으므로 클라이언트는 브라우저에 저장된 공개키로 복호화 또한 가능하다. 만약, CA 리스트 중 해당된 인증서가 없다면 Not Secure 경고문구가 뜬다.)
대칭키와 비대칭키 혼합하여 사용(비대칭키 암호화, 복호화 과정은 컴퓨터에 부담을 줌)

HTTPS는 완벽한가?

암호화 비용

평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 더 많이 요구한다. 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대 당 처리할 수 있는 리퀘스트의 수가 상대적으로 줄어들게 된다. 하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함께 이용한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다. 따라서 웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용하는 방식에서 현재 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있다.