HTTPS: 안전한 웹 통신을 위한 필수 프로토콜

 HTTPS는 HTTP(Hypertext Transfer Protocol)에 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 더해 데이터 전송을 암호화하여 보안을 강화한 프로토콜이다.

HTTP의 가장 큰 문제는 데이터 전송이 암호화되지 않아 제3자가 도청할 수 있다는 것이다. HTTPS는 SSL/TLS 기술을 활용해 데이터를 안전하게 암호화하여 이러한 문제를 해결할 수 있다.

HTTPS는 대칭키 암호화, 공개키 암호화, 디지털 서명 등의 다양한 암호화 기술을 사용하여 데이터 전송의 보안성을 높이고 이를 통해 클라이언트와 서버 간에 전송되는 중요한 정보를 안전하게 보호할 수 있다.

본 글에서는 HTTPS의 작동 원리, 핵심 기술, 장단점 등을 자세히 살펴보고자 한다. 이를 통해 HTTPS의 중요성과 웹사이트 보안 강화를 위한 방법을 이해할 수 있을 것이다.

HTTPS 작동 원리

HTTPS는 대칭키 암호화와 공개키 암호화 기술을 함께 활용하여 데이터 전송의 보안성을 높인다.

대칭키 암호화 방식은 암호화와 복호화에 동일한 키를 사용하는 방식이다.

두 사용자가 미리 공유한 대칭키를 이용해 메시지를 암호화하고 복호화할 수 있다. 이 방식은 빠르고 효율적이지만 키 공유 과정이 필요하다.

공개키 암호화 방식은 암호화와 복호화에 서로 다른 키를 사용한다. 사용자 B가 비밀키와 공개키를 생성하고, 공개키는 누구나 사용할 수 있다.

사용자 A가 공개키로 메시지를 암호화하면 B의 비밀키로만 복호화할 수 있다. 이를 통해 키 공유 과정 없이 안전한 메시지 전송이 가능하다.

HTTPS는 이러한 대칭키와 공개키 암호화 기술을 함께 사용한다.

서버 인증을 위해 디지털 인증서가 활용되는데, 인증기관(CA)은 서버의 정보를 기반으로 서버의 공개키가 포함된 인증서를 발급한다.

클라이언트는 인증서를 통해 서버의 공개키를 얻고, 이를 이용해 대칭키를 전달할 수 있다. 이를 통해 안전한 데이터 전송이 가능해진다.

 

SSL/TLS HandShake

SSL/TLS HandShake 과정은 서버와 클라이언트가 HTTPS 통신을 하기 전에 이루어지는 과정인데, 왜 이렇게 복잡한 과정을 거쳐야 하는걸까? 결론부터 말하자면, 안전한 대칭키를 서버와 클라이언트가 공유하기 위해서이다.

 

목적을 알고나면 해당 과정을 이해하기 쉬워진다. 

서버와 클라이언트는 데이터를 암호화하여 통신하기 위해 대칭키를 사용하려고 하는데, 이 대칭키를 서로 공유하는 과정에서 네트워크 상에 노출되기 때문이다. 

 

HTTPS 에서는 대칭키를 직접적으로 네트워크에 노출하는 대신에 특정한 값(프리마스터 시크릿, 서버 랜덤 값, 클라이언트 랜덤 값 등)을 암호화하여 서로 공유하고 해당 값으로 각각 대칭키를 생성한다.

 

이때 암호화할때 사용되는 키가 네트워크 상에 노출되어도 되는 공개키이다. (Server Hello 과정) 따라서 대칭키를 암호화할때 사용되는 공개키가 안전하다는 것을 인증기관(CA)이 인증만 해주면 클라이언트와 서버는 마음놓고 해당 공개키를 사용할 수 있다.

 

해당 목적을 이해했으니 과정은 따라가기만 하면 된다.

1. 클라이언트가 서버에 접속 요청을 한다.
2. 서버는 자신의 인증서를 클라이언트에게 전송한다. 이 인증서에는 서버의 공개키와 인증기관 정보가 포함되어 있다.
3. 클라이언트는 인증서에 포함된 정보를 확인하여 안전한 서버인지를 확인한다. 이때 클라이언트가 사전에 저장하고 있는 인증기관의 공개키를 사용하여 인증서의 유효성을 검증한다.
4. 클라이언트는 *특정 값으로 대칭키를 생성하고, 서버의 공개키로 이 *특정 값을 암호화하여 서버에 전송한다.
5. 서버는 자신의 비밀키로 이 값을 복호화하여 대칭키를 생성한다.

*4번 과정에서 대칭키를 생성할때 사용되는 값은 클라이언트가 생성한 임의의 시크릿 값인데.  이를 프리마스터 시크릿이라고 한다. 이 값은 대칭키 생성을 위한 기본 정보가 되고, 클라이언트 프리마스터 시크릿을 서버의 공개키로 암호화하여 전송하게 된다. 

 

이제 클라이언트와 서버는 동일한 대칭키를 공유하게 되었으므로, 이 대칭키를 사용하여 데이터를 암호화하고 전송할 수 있다.

 

클라이언트와 서버는 암호화 된 프리 마스터 시크릿을 각자의 랜덤 값을 사용하여 대칭 키(세션 키)를 생성하는데, 이 대칭 키가 이후의 데이터 전송에 사용되는 것이다.

이와 같은 SSL/TLS 핸드셰이크 과정을 통해 세션키를 공유하고, 해당 세션키로 데이터를 암호화하여 클라이언트와 서버는 안전한 통신 채널을 확립할 수 있다.

 

Q, 클라이언트와 서버는 같은 프리 마스터 시크릿을 랜덤값을 사용하여 대칭키를 생성하는 이유가 무엇일까?

랜덤 값을 사용하여 생성된 대칭 키는 각 세션에 대해 고유하게 만들지는데, 이는 동일한 프리 마스터 시크릿을 사용하더라도, 각 세션이 서로 다른 키를 사용할 수 있도록 할 수 있다.

HTTPS에서 대칭키는 직접적으로 전송되지 않으며, 프리 마스터 시크릿이 암호화되어 안전하게 교환되기 때문에 공격자가 대칭키를 쉽게 알아내는 것은 어렵긴 하지만, 공격자가 이전 세션의 데이터를 오랜 시간에 걸쳐 분석하면 대칭키를 알아낼 가능성이 있을 수 도 있다.

 

랜덤 값을 추가함으로써 공격자가 이전 세션의 대칭 키를 추측하거나 재사용하는 것을 방지할 수 있는 것이다.

디지털 인증서와 인증 기관의 역할

HTTPS에서 디지털 인증서와 인증 기관은 매우 중요한 역할을 한다. HTTPS를 사용하여 서버에 접속하려면 서버가 반드시 인증기관으로부터 인증서를 발급받아야 하는데,

이 인증서에는 서버의 도메인, 서버 측 공개키, 인증기관 정보 등이 포함되어 있다. 클라이언트는 이 인증서를 통해 서버의 공개키를 얻을 수 있고 클라이언트는 이 공개키를 이용하여 대칭키를 서버에 전달한다.

이 대칭키로 데이터를 암호화하여 안전하게 통신할 수 있다.

인증기관은 비밀키를 사용하여 서버의 정보를 기반으로 인증서를 발급하므로

클라이언트는 웹 브라우저에 사전 저장된 인증기관의 공개키를 통해 서버의 인증서를 검증할 수 있다.

이를 통해 클라이언트는 접속한 서버가 신뢰할 수 있는 서버인지 확인할 수 있다.

즉, 디지털 인증서와 인증 기관은 HTTPS의 핵심 기술로서 서버 인증과 클라이언트-서버 간 암호화 통신을 가능하게 해 주는 중요한 기관이다. 따라서 HTTPS를 안전하게 사용하기 위해서는 신뢰할 수 있는 인증 기관이 발급한 유효한 인증서를 사용해야 하는 것이 중요하다.

HTTPS의 장점

HTTPS의 가장 큰 장점은 데이터의 기밀성, 무결성, 인증 등을 보장한다는 것이다.

HTTPS는 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 클라이언트와 서버 간 데이터 전송을 암호화하는데, 이를 통해 중간에 도청되더라도 해당 정보를 알 수 없게 만들어 사용자의 개인정보, 금융 거래 내역 등 중요한 데이터를 안전하게 보호할 수 있다.

또한 HTTPS는 서버 인증 기능을 제공한다.

HTTPS를 사용하려면 서버가 인증기관으로부터 인증서를 발급받아야 하고, 클라이언트는 이 인증서를 통해 접속한 서버가 신뢰할 수 있는 서버인지 확인할 수 있다. 이를 통해 사용자는 안전한 사이트에 접속하고 있다는 것을 확신할 수 있다.

 

공격자가 자신이 만든 인증 기관(Certificate Authority, CA)을 통해 신뢰된 인증서를 생성하는 것은 이론적으로 가능하지만 브라우저와 운영 체제는 신뢰된 CA 목록을 주기적으로 업데이트하며, 의심스러운 활동이 발견되면 해당 CA를 블랙리스트에 추가하므로, CA에 대한 의심은 접어두어도 무방하다.

이처럼 HTTPS의 데이터 암호화와 서버 인증 기능은 웹사이트의 신뢰성과 안전성을 크게 향상시킨다. 따라서 개인정보 보호와 데이터 보안이 중요한 웹사이트에서는 HTTPS의 적용이 필수적이라고 할 수 있다.

HTTPS의 단점

HTTPS의 가장 큰 단점은 계산 오버헤드와 인증서 관리 등의 복잡성이다.

HTTPS는 SSL/TLS 프로토콜을 사용하여 데이터를 안전하게 암호화하지만, 이를 위해 클라이언트와 서버 간의 키 교환 과정(SSL/TLS HandShake)과 암호화/복호화 작업이 필요하다. 이로 인해 HTTP 대비 처리 속도가 느리다는 단점이 있다.

또한 HTTPS를 사용하려면 서버가 인증기관으로부터 인증서를 발급받아야 한다.

이 인증서에는 서버의 공개키와 도메인 정보가 포함되어 있어 관리가 필요하고, 인증서가 유효하지 않거나 만료되면 사용자에게 경고 메시지가 나타나 불편을 초래할 수 있다.

인증서를 갱신하는 작업은 서버 관리자 입장에서 굉장히 귀찮지만.. 이마저도 요즘은 자동화하는 추세이다.

HTTPS에도 보안 위협이 존재한다.

암호화된 데이터 자체는 보호되어서 안전하다고 생각할 수 있지만, 여전히 악의적인 공격자가 중간자 공격(Man-in-the-Middle Attack)을 통해 클라이언트와 서버 사이의 통신을 가로채고 정보를 탈취할 수 있다.

 

공격자가 통신 경로에 개입할 수 있는 여러 방법이 있는데,

예를 들어, 공격자는 사용자가 신뢰할 수 있는 인증서를 위조할 수 있다. 사용자가 가짜 인증서에 속아 HTTPS 연결을 시도하면, 공격자는 암호화된 통신을 해독하고 수정할 수 있게 된다..

이러한 HTTPS의 단점을 극복하기 위해서는 계산 성능 향상, 인증서 관리 자동화, 보안 취약점 점검 등의 노력이 필요합니다. 특히 HTTP 2.0에서 TLS 사용이 필수화되는 등 HTTPS의 성능이 개선되고 있어, 향후 HTTPS의 확산이 더욱 가속화될 것으로 예상된다.

종합적으로 HTTPS는 데이터 보안과 사이트 신뢰성 제고를 위해 필수적인 기술이지만, 계산 오버헤드와 관리의 복잡성과 같은 단점도 존재한다. 이러한 단점을 개선하기 위한 지속적인 노력이 필요하다.