동형2

HTTP(Hypertext Transfer Protocol)은 이름에서도 알 수 있듯이 text를 전송하는 프로토콜이다.

최근에는 text 뿐만 아니라 정말 다양한 정보들이 HTTP 프로토콜을 이용하여 주고 받아진다. 

또한 동시에 HTTP 위에서 민감한 정보를 전송하는 수요도 증가하기 시작했는데, 

보안이 요구되기 시작함에 따라 SSL(Secure Socket Layer)같은 프로토콜이 디자인되었다.

HTTPS는 이러한 보안 레이어 위에서 HTTP를 이용하는 구조로, 따라서 HTTP에 담긴 평문 데이터를 암호화해서 주고받을 수 있다.

1. HTTP Over TLS

RFC2818은 HTTP Over TLS란 이름으로 말 그대로 TLS 레이어 위에서 HTTP를 전송하는지에 대해 담고 있다.

여기서 중요한 하위 레이어인 TLS은 두 가지 역할을 수행한다.

1. End Host 간 안전한 데이터 전송 및 무결성 확인

2. 인증서를 통해 통신 상대가 신뢰할 수 있는지 확인

데이터를 암호화하여 전송하고, 받는 측에서는 데이터를 복호화하여 HMAC 알고리즘을 이용해 무결성을 검증한다.

또한 통신 시작 전 상대의 Certificate(보통 서버의 Certificate)를 받아 통신 상대가 신뢰가능한지 검증한다.

2. TLS

위에서 말했던 2가지 역할은 모두 TLS Handshake로 부터 시작된다.

이 Handshake를 통해 서버와 클라이언트는 Cipher Suite라는 구조체를 정의하게 되고,

이 구조체를 이용하여 통신에 사용할 암호화 관련 알고리즘을 정의한다.

또한 Handshake 과정을 통해 인증서를 전송하고, 암호화에 사용할 Symmetric 키를 정의한다.

이제 Handshake 과정을 자세히 알아보자.

클라이언트-서버 구조로 먼저 처음엔 Client가 TLS 세션을 시작하는 ClientHello 메시지를 보내며 시작된다.

1) ClientHello

이 단계에서는 클라이언트가 사용 가능한 Cipher Suite 리스트와, 기타 메타데이터들을 전송하게 된다.

메타데이터 중 Session ID는 서버가 클라이언트 정보를 식별해, 최근에 연결되었던 세션이면 서버와 클라이언트는 이후 과정을 생략하여 Handshake를 끝내고 기존 Cipher Suite와 비밀키를 이용해 연결을 시작한다.

2) ServerHello

ClientHello를 받은 서버는 ServerHello 메시지로 클라이언트에 응답하게 된다.

이 메시지에는 클라이언트가 보낸 Cipher Suite 리스트 중 하나가 포함되고, 이 Cipher Suite를 이용하여 암호화를 진행한다

여기서 서버는 Cipher Suite로 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 을 선택했는데, 이는

1. 대칭키 교환 방식은 ECDHE( Elliptic-Curve 디피헬만)

2. 인증서 서명 방식 RSA

3. 대칭키 암호화 알고리즘 AES128_GCM (Galois/Counter Mode)

4. HMAC 알고리즘 SHA256

을 사용한다는 의미이다.

3) Certificate

서버는 ServerHello 이외에도 여러 메시지를 전송하게 되는데, 첫번째로 Certificate이다.

이 Certificate에는 Root CA의 인증서부터 서버의 인증서까지 Certificate chains을 전송하게 된다.

필요에 따라 서버가 클라이언트의 신원이 필요할 경우 CertificateRequest를 클라이언트에 전송해

클라이언트 또한 서버에게 Certificate 메시지를 전송할 수 있다.

이 과정을 통해서 상대방의 서명된 인증서를 받고 이를 검증함으로써 통신상대가 신뢰할 수 있는지 검증하게 된다.

다음 링크에서는 Certificate chain 과정에 대해 자세히 설명해주고 있다.

https://support.dnsimple.com/articles/what-is-ssl-certificate-chain

4) ServerKeyExchange

Diffie Hellman을 키 교환 알고리즘을 사용할 경우 KeyExchange 과정을 통해 암호화에 사용할 키를 생성하기 위한 데이터를 주고받는다.

서버는 ServerKeyExchange, 클라이언트는 ClientKeyExchange 메시지를 통해 데이터들을 주고받는다.

5) ServerHelloDone

ServerHello 부터 시작해 필요한 메시지들을 모두 전송하면 서버는 ServerHelloDone을 통해 보낼 메시지는 다 보냈다고 알린다.

6) ChangeCipherSpec

데이터 전송 및 검증에 필요한 모든 데이터를 교환하고 암호화에 사용할 비밀키를 생성했다면 서버와 클라이언트는 각각 ChangeCipherSpec 메시지를 통해 이제 다음부터 보낼 데이터는 암호화 해서 보내겠다고 알린다.

7) Finished

Handshake 과정을 종료하고 이젠 Application Data를 암호화하여 전송하고, 받는 측에서는 복호화하여 무결성을 검증한다.

3. 참고

https://luavis.me/server/tls-101

https://rsec.kr/?p=455

1. Domain ? 

웹브라우저를 통해 네이버를 접속하기 위해서 우리는 naver.com 이란 도메인을 이용한다. 하지만 웹 브라우저가 서버와 통신하기 위해서는 naver.com 가 아닌 서버의 IP 주소를 알아야 하는데 이 때 도메인을 IP 주소로 변환하는데 도움을 주는 것이 DNS 이다. 이렇게 도메인을 IP로 변환한 이후에 웹브라우저는 본격적으로 서버에 요청을 보내게 된다.

2. DNS 질의

DNS 정보를 알기 위해 클라이언트는 DNS 질의(DNS Query)를 서버에 보내게 된다. 

이 때 매번 DNS 서버에 질의를 할 수 없으므로 브라우저와 운영체제는 DNS 레코드 정보를 캐싱하게 된다. 만약 도메인 정보가 캐싱되어 있으면 그대로 변환하고, 없으면 이제 IP를 얻기 위한 DNS Query가 시작된다.

먼저 가장 먼저 로컬에 등록된 DNS Resolver로 쿼리를 보낸다. DNS Resolver는 클라이언트에게 적절한 응답을 할 책임이 있다. 

먼저 DNS Resolver는 클라이언트의 쿼리를 받고 자신의 캐시를 확인한다. 이 때 캐싱되어 있으면 응답하고,

아니면 루트 네임 서버에 쿼리한다. 루트 네임 서버는 전 세계에 13대 밖에 없다고 한다.

루트 네임 서버는 쿼리를 받고 여기서 TLD(Top-Level-Domain) 서버의 주소를 응답한다.  naver.com 의 경우 TLD는 com 으로, 루트 네임 서버는 .com DNS 서버의 주소를 응답해 준다.

이제 DNS Resolver는 TLD DNS 서버에 Query를 보내고, TLD DNS 서버도 마찬가지로 캐싱되어 있으면 응답하고, 그렇지 않다면 해당 도메인의 네임서버의 주소를 응답해주게 된다. 

마지막으로 해당 도메인의 네임서버는 DNS 레코드를 갖고 있으며, DNS Resolver -> Client 순으로 응답하게 된다.

DNS Query를 빨리 해결하기 위해서 서버들은 다양한 정보를 캐싱해둔다. 이 때 DNS 레코드의 TTL(Time-To-Live)란 캐싱된 정보가 유효한 시간으로 이 시간 동안은 캐싱을 유지한다.

References

https://www.cloudflare.com/ko-kr/learning/dns/what-is-dns/