[Network]TLS, HTTPS

예전 글에서 TCP/IP를 사용하는 네트워크 집합체인 인터넷과 그 안에서 이루어지는 서비스인 웹,

 

그리고 클라이언트-서버 아키텍처와 그 사이의 메시지 교환 규약인 HTTP에 대해 알아봤었다.

 

또한 IP 프로토콜의 한계를 극복하는 프로토콜은 TCP 말고도 UDP가 존재하는데,

 

데이터의 신뢰성이 중요한 경우엔 TCP를 사용한다고도 했었다.

 

2022.08.02 - [Development/Network] - [네트워크]TCP/IP

2022.08.02 - [Development/Network] - [네트워크]URL, URI, Domain, DNS

2022.08.03 - [Development/Network] - [네트워크]CORS(Cross-Origin Resource Sharing)

2022.08.04 - [Development/Network] - [네트워크]HTTP

[네트워크]HTTP

이번 글에선 HTTP에 TLS를 통한 보안이 적용된 HTTPS에 대해 알아보자.

 

 

Transport Layer Security(TLS) and HTTPS

 

Transport Layer Security란 직역하면 전송 계층 보안이라는 뜻으로,

 

한 마디로 말하자면 인터넷에서 데이터를 암호화해서 주고받는 통신 규약, 즉 프로토콜이다.

 

서버에 접속하는 클라이언트가 안전하게 정보를 주고받을 수 있도록 보조하는 기술이라고 보면 되겠다.

 

예전에 TCP/IP의 구조에 대해 보면서 프로토콜을 따라 데이터를 전송하는 모습을 본 적이 있는데,

 

다시 꺼내보면 아래와 같다.

 

TLS는 그 이름답게 Application Layer와 Transport Layer 사이에서 암호화를 담당하는 프로토콜이다.

 

조금 더 구체적으로는 Application Layer에서 동작하며, Transport Layer와의 결합을 담당한다고 볼 수도 있다.

 

SSL, TLS

 

SSL(Secure Sockets Layer)은 1995년 미국의 넷스케이프 커뮤니케이션사가 발표한 보안 프로토콜이다.

 

이 프로토콜의 사용 범위가 점차 넓어지다가 1999년 국제 인터넷 표준화 기구(IETF)가 관리하게 되면서

 

SSL 3.0을 업그레이드 한 버전의 이름이 TLS 1.0이다.

 

즉, SSL과 TLS는 사실상 같은 규약을 가리키는 단어이며, 실제로는 SSL을 더 많이 사용한다고 한다.

 

또한 이런 위치를 가지고 있는 TLS 위에 HTTP를 얹어 보안된 통신을 하는 규약을 HTTPS라고 부른다.

 

HTTPS라는 이름 자체도 HTTP(HyperText Transfer Protocol) + S(Secure)의 합성어이다.

 

계속해서 TLS가 더해진 HTTPS는 아래와 같은 보안상의 특징을 가지며, 그 종류는

 

• 암호화(Encryption)
• 인증서(Certificate)

이다. 하나씩 살펴보자.

 

Encryption

 

암호화란 간단하게 말하면 제삼자가 클라이언트-서버 사이에서 데이터를 가로채지 못하도록 하는 것이다.

 

이를 위해 클라이언트-서버는 미리 약속된 방식만을 이용해 데이터를 암호화해서 주고받는다.

 

TLS는 바로 이 데이터의 암호화를 처리하는데, 그림으로 보면 대략 아래와 같다.

 

 

TLS가 적용되지 않은 HTTP의 경우 제삼자가 중간에서 패킷을 가로채면 중요한 데이터를 그대로 읽을 수 있다.

 

하지만 HTTPS의 경우 서버만 해석할 수 있는 규칙에 따라 데이터가 암호화되어있기 때문에 내용을 파악할 수 없게 된다.

 

TLS는 이 암호화를 보안상, 성능상의 이유로 두 가지 방식을 혼용하고 있는데, 

 

• 대칭 키(Symmetric Key)
• 공개 키(Public Key), 혹은 비대칭 키(Asymmetric Key)

가 그것이다.

 

대칭 키(Symmetric Key)

 

대칭 키는 암호화와 복호화(암호를 푸는 행위)에 같은 키를 사용하는 알고리즘을 말한다.

 

이 말은 공통의 암호 키를 클라이언트와 서버가 공유해야 한다는 것을 의미하는데,

 

연산 속도가 빠르다는 장점과 함께 데이터를 주고받는 주체들 사이에 암호 키를 전달하는 것이 어렵다는 단점이 있다.

 

대칭 키가 유출되는 순간 암호가 무용지물이 되기 때문인데, 이를 극복하기 위해 나온 것이 공개 키이다.

 

공개 키(Public Key), 혹은 비대칭 키(Asymmetric Key)

 

공개 키는 대칭 키와 다르게 암호화와 복호화에 다른 키를 사용하는 알고리즘이다.

 

두 개의 키 중 하나(암호화 키)를 공개키, 나머지 하나(복호화 키)를 비공개 키로 한 뒤 공개 키를 말 그대로 공개한다.

 

이후 클라이언트가 공개 키를 이용해 데이터를 암호화한 뒤 전송하면 비공개 키의 소유자가 이를 복호화하는 방식이다.

 

이 과정에서 공개 키가 유출된다고 해도 비공개 키가 없이는 복호화가 어렵기 때문에 비교적 안전하다.

 

암호화 키만 가지고는 복호화하는데 시간이 아주 오래 걸리기 때문이다.

 

이처럼 암호 키를 전달하는 방식이 간단하지만, 공개 키는 연산에 시간이 많이 소요되는 편이다.

 

TLS Handshake

 

위와 같은 장단점 때문에 HTTPS는 두 방식을 섞어서 사용한다.

 

구체적으론 대칭 키를 공개 키 방식으로 교환 후 데이터는 대칭 키 방식으로 주고받는 방식을 사용하는데,

 

이 과정을 간략하게 표현한 것이 바로 TLS Handshake이다.

 

이는 이전 글에서 살펴봤던 TCP 3-Way Handshake를 보완하는데,

 

그림을 보면 아래와 같다.

 

 

Certificate

 

TLS의 두 번째 특징은 서버가 전달한 인증서를 브라우저가 확인할 수 있다는 것이다.

 

여기서 인증서란 서버의 신원을 보증하는 신분증과 같은 역할을 하는데,

 

서버에서 제공하는 서비스의 정보와 함께 위에서 도입한 공개 키에 대한 정보를 담고 있다.

 

또한 이 인증서를 발급 및 보증해주는 기관을 CA(Certificate Authority), 즉 (공인)인증기관이라 부르는데,

 

CA는 자신의 비공개 키를 이용해서 서버의 공개 키를 암호화한 뒤 인증서를 발급하게 된다.

 

이어서 서버는 위 그림처럼 인증서를 전달하고,

 

브라우저는 미리 가지고 있던 CA의 공개 키를 이용해 서버의 인증서를 복호화한다.

 

즉, 브라우저는 내부적으로 CA의 리스트 및 그 공개 키를 미리 파악하고 있다.

 

이렇게 얻어낸 인증서의 정보를 바탕으로 서버를 검증한 뒤 데이터 전송을 시작하기 때문에

 

중간에 개입하려는 공격 및 보안 위험에서 클라이언트와 그 데이터를 지킬 수 있게 된다.

 

또한 대부분의 브라우저는 CA가 발급한 인증서를 이용하지 않는 서버에 접속할 시 경고를 띄우며,

 

클라이언트가 안전한 서버를 이용할 수 있도록 유도한다.

 

Summary

• HTTP = HyperText Transfer Protocol
• TLS = Transport Layer Security
• HTTP + TLS = HTTPS(Secure)
• HTTPS는 암호화와 인증서라는 특징을 갖는다.
• 암호화 방식은 대칭 키, 공개 키의 방식이 있으며 HTTPS는 두 방식을 혼용한다.
• 인증서는 CA에서 발급하며, 브라우저는 CA에 대한 정보를 미리 가지고 있다.