[CS] HTTP, HTTPS
원글
1. HTTP, HTTPS의 차이점
HTTP는 인터넷상에서 정보를 주고 받는데 사용되는 프로토콜로 HTTP는 암호화되지 않은 텍스트 데이터를 전송하므로 보안이슈가 발생할 수 있다.
HTTPS의 S는 Secure로 HTTP와 HTTPS의 가장 큰 차이점이다.
SSL(Secure Sockets Layer) 업그레이드 버전인 TLS(Transport Layer Security) 인증서를 이용해 데이터를 암호화해 주고받는다.
2. HTTPS에 사용되는 SSL/TLS
브라우저(클라이언트)와 서버(웹사이트) 사이에 전송되는 데이터를 암호화하여 인터넷 연결을 보호하기 위한 표준 기술이다.
SSL이 먼저 개발되었으며 이를 업그레이드 한 것이 TLS다.
현재 SSL은 사용하지 않고 있으며, 편의상 SSL 인증서라고 부르지만 이는 TLS를 의미한다.
3. HTTPS의 동작 과정
- 브라우저가 서버 접속
- 서버가 TLS 인증서를 브라우저에게 전송
- 브라우저는 서버가 보내온 인증서를 검토 (발급기관, 만료일 등)
- 브라우저가 TLS 연결을 위해 랜덤한 대칭키를 생성하며 이는 데이터 암호화 및 복호화에 사용됨
- 브라우저가 서버에게 대칭키를 전달하기 위해 공개키 암호화 방식을 사용함
- 서버가 자신의 개인키를 사용해 대칭키 복호화
- 서로 대칭키를 사용해 데이터를 암호화하여 소통
4. 대칭키, 개인키 암호화 방식
HTTPS에서는 대칭키와 공개키 암호화 방식을 모두 사용한다.
대칭키 암호화 방식은 서버와 클라이언트가 암호화와 복호화에 같은 비밀키를 사용하는 방식으로 이는 데이터 전송 속도가 빠르고 간단한 암호화 방식이지만, 비밀키가 노출될 경우 보안성이 크게 떨어지게 된다.
따라서 HTTPS에서는 대칭키 암호화 방식을 사용하여 데이터를 암호화하고, 이 대칭키를 전달하는 과정에서 공개키 암호화 방식을 사용한다.
공개키 암호화 방식은 서버와 클라이언트가 각각 다른 비밀키를 가지고 있는 방식이다.
서버는 공개키를 클라이언트에게 제공하고, 클라이언트는 이 공개키를 이용하여 대칭키를 암호화하여 서버에 전달한다.
서버는 이 암호화된 대칭키를 자신의 개인키로 복호화하여 대칭키를 얻어내고, 이 대칭키를 사용하여 데이터를 암호화한다.
이 과정에서 중간에 도청자가 끼어들더라도, 공개키로 암호화된 대칭키를 해독할 수 없기 때문에 데이터의 기밀성이 보장된다.
또한, 서버 측의 개인키는 서버 외부에서 알 수 없도록 보안적으로 관리되기 때문에 데이터의 무결성과 인증성이 보장된다.
5. HTTPS 구현 방법
- SSL/TLS 인증서 발급
- 인증서는 인증기관(CA, Certificate Authority)에서 발급해주며, “서버의 도메인 이름, 공개키(Public Key), 발급자 정보, 유효 기간”과 같은 정보가 들어있다.
- 웹 서버 구성
- 웹 서버(Nginx, Apache, Spring 등)에 적용 해서 HTTPS를 사용할 수 있도록 설정해야 하며, 발급받은 TLS 인증서와 서버의 개인키를 등록한다.
- 클라이언트와의 통신 (TLS Handshake)
- 클라이언트는 서버와 연결을 시도할 때 SSL/TLS 핸드셰이크 과정을 거친다. 이 과정에서 서버는 발급받은 인증서를 클라이언트에게 제공하고, 클라이언트는 인증서의 정보를 확인한 후, 서버의 공개키를 사용하여 세션 키를 생성한다.
- 암호화 통신 (세션 키 사용)
- 브라우저와 서버는 위에서 만든 대칭키(세션 키)를 사용해 데이터를 암호화해서 주고받는다.
6. HTTPS를 사용하며 발생할 수 있는 성능 이슈와 개선방안
암호화/복호화 작업: HTTPS는 암호화를 사용하여 통신을 보호한다. 암호화 및 복호화 작업은 CPU를 많이 사용하므로, 작업량이 많아질수록 서버의 성능에 영향을 줄 수 있다.
-> HTTPS의 성능 이슈 중에서 가장 대표적인 것은 암호화/복호화 과정에서 발생하는 부하이다. 이러한 부하를 해결하기 위해 하드웨어 가속 기술을 사용할 수 있으며, 하드웨어 가속 기술은 SSL/TLS 암호화/복호화 과정을 CPU 대신 별도의 하드웨어 장치에서 처리함으로써 처리 속도를 향상시킨다.
핸드쉐이크 오버헤드: HTTPS 연결을 설정하는 과정에서 핸드쉐이크라는 절차를 거치게 됩니다. 이 과정에서 전송되는 데이터양이 많기 때문에, 핸드쉐이크 오버헤드가 발생할 수 있습니다.
-> 암호화 알고리즘 최적화: HTTPS에서 사용되는 대표적인 암호화 알고리즘으로는 AES, RSA, SHA 등이 있다. 이러한 알고리즘들은 성능 향상을 위해 최적화될 수 있다. 예를 들어, RSA 알고리즘은 키의 크기에 따라 처리 속도가 크게 달라질 수 있기 때문에 키 크기를 최소화하는 것이 좋다.
캐시 불가능: HTTPS에서는 캐시가 불가능하다. 왜냐하면, 캐시된 데이터가 변조될 가능성이 있기 때문이다. 따라서, 매번 요청할 때마다 서버에서 새로운 데이터를 가져와야 하므로 성능에 영향을 줄 수 있다.
-> 캐시: HTTPS의 경우 매번 인증서를 다운로드해야 하기 때문에 초기 연결 시간이 길어질 수 있다. 이를 해결하기 위해서는 캐시를 이용해야 한다. 캐시를 이용하면 인증서를 다운로드하지 않고 기존에 다운로드한 인증서를 사용함으로써 연결 시간을 단축시킬 수 있다.
-> 세션 재사용: HTTPS는 기본적으로 연결마다 새로운 세션을 생성한다. 이러한 세션 생성 과정은 처리 시간이 오래 걸리므로, HTTPS에서는 기존에 생성된 세션을 재사용하는 방법을 이용해 성능을 개선할 수 있다.
CDN 사용 제약: HTTPS 연결을 설정할 때, 도메인 이름이 반드시 일치해야 한다. CDN을 사용하는 경우 도메인 이름이 변경되므로 HTTPS를 사용하기 어렵다. 이러한 경우에는 CDN에서 HTTPS를 지원하도록 설정해야 한다.
-> CDN(Content Delivery Network): HTTPS에서 가장 큰 성능 이슈 중 하나는 지리적으로 떨어진 클라이언트와 서버 간의 지연 시간이다. 이를 해결하기 위해 CDN(Content Delivery Network)을 이용해야 한다. CDN은 전 세계에 분산된 캐시 서버를 이용하여 클라이언트와 가까운 서버에서 콘텐츠를 제공함으로써 지연 시간을 최소화 시킬 수 있다.
앞의 두 가지는 HTTPS의 성능 이슈를 해결하고 동시에 보안성 문제를 높이지 않는 방법이고, 뒤의 세 가지는 HTTPS에서 적용이 가능하나 보안성 문제와 관련된 취약점이 존재할 수 있어 충분한 보안 검사가 필요하다.
7. 서버측에서 주의해야 할 보안 이슈
-
인증서 유효성 검증: HTTPS를 사용하면 서버는 클라이언트에게 인증서를 제공하여 신뢰성을 보장한다. 따라서 서버 측에서는 인증서의 유효성을 검증하여 위조된 인증서를 사용한 공격을 방지해야 한다.
-
암호화 강도: HTTPS는 암호화된 통신을 제공하여 데이터의 안정성을 보장한다. 그러나 암호화 알고리즘의 강도에 따라 보안 수준이 달라질 수 있다. 서버 측에서는 보안 수준이 높은 암호화 알고리즘을 사용하여 공격에 대한 대비를 해야한다.
-
취약한 SSL/TLS 버전 사용: 오래된 SSL/TLS 버전은 보안 취약점이 존재하여 공격자가 중간자 공격을 수행할 수 있다. 따라서 서버 측에서는 최신 버전의 SSL/TLS 프로토콜을 사용하여 보안 취약점을 방지해야 한다.
-
HTTPS 트래픽 감시: HTTPS 통신은 암호화되어 있기 때문에 보안 검사나 감시가 어렵다. 하지만 일부 악성코드는 HTTPS 트래픽을 통해 악성코드를 전파하거나 민감한 정보를 수집하는 등의 공격을 하기 때문에, 서버 측에서는 HTTPS 트래픽을 감시하고 이상한 패턴을 탐지할 수 있는 시스템을 구축해야 한다.
참고
Leave a comment