DNS, 3-way Handshake, SSL/TLS

오늘은 브라우저 주소창에 무언가를 입력했을때 네트워크상에서 일어나는 일들을 알아보겠습니다.

 

브라우저에서 주소창에 "사과"를 입력하면 다음과 같은 과정이 일어납니다.

브라우저는 사용자가 입력한 내용을 분석합니다. 입력된 " 사과 "는 URL 형식이 아니므로 기본 설정된 검색 엔진을 통해 검색하려고 합니다.

 

검색 엔진의 URL을 생성합니다. 예를 들어, https://www.google.com/search?q= 사과 와 같은 형태로 변환하여 요청을 준비합니다. 검색 엔진의 도메인 이름인 www.google.com을 IP 주소로 변환하기 위해 DNS(Domain Name System)를 확인합니다. 이때 브라우저는 먼저 자신의 캐시를 확인하고, 없으면 운영 체제(OS) 캐시와 라우터 캐시를 차례로 조회합니다. 그래도 IP 주소를 찾지 못하면 ISP(통신사)의 DNS 서버나 상위 DNS 서버에 쿼리를 보냅니다.

 

IP 주소가 확인되면, 브라우저는 검색 엔진 서버와 연결하기 위해 TCP를 통해 3-way Handshake 과정을 진행합니다. 이 과정에서 브라우저는 서버와 연결 요청(SYN)을 보내고, 서버는 이를 수락(SYN-ACK)하며, 브라우저가 최종 확인(ACK)을 보내 연결이 확립됩니다.

 

HTTPS가 사용되는 경우, 브라우저와 서버는 SSL/TLS 프로토콜을 통해 안전한 통신을 설정합니다. 이 과정에서 암호화 키를 교환하고, 서버가 신뢰할 수 있는 사이트임을 보장하는 인증서를 확인합니다.

 

브라우저는 검색 엔진 서버에 HTTP 요청을 보냅니다. 이 요청은 "GET /search?q= 사과 HTTP/1.1" 형식으로 이루어지며, 요청 헤더에는 브라우저 정보, 쿠키, 언어 설정 등이 포함됩니다.

 

검색 엔진 서버는 브라우저의 요청을 분석하고 데이터베이스를 검색합니다. " 사과 "와 관련된 정보를 찾은 후, 이를 기반으로 HTML, CSS, JavaScript로 구성된 응답 데이터를 준비합니다.

 

서버는 HTTP 응답을 브라우저로 반환합니다. 이 응답에는 "HTTP/1.1 200 OK"와 같은 상태 코드와 함께 검색 결과 페이지의 데이터가 포함됩니다.

 

브라우저는 응답 데이터를 처리하여 HTML을 파싱하고 DOM(Document Object Model)을 생성합니다. 이어서 CSS를 적용해 스타일을 렌더링하고, JavaScript를 실행하여 동적 요소를 처리합니다.

 

이 모든 과정이 완료되면, 검색 결과 페이지가 브라우저 화면에 렌더링되어 사용자가 볼 수 있게 표시됩니다.

 

 

이 일련의 과정속에서 우리는 알아야할게 너무나도 많습니다.

DNS는 뭐고  3-way Handshake 는 뭐고 SSL/TLS 프로토콜은 뭔데 안전한가?

 

DNS (Domain Name System)

DNS는 도메인 이름을 IP 주소로 변환해주는 시스템입니다. 인터넷에서 컴퓨터, 서버, 또는 다른 장치는 고유한 IP 주소(예: 192.168.1.1 또는 2606:4700:4700::1111)로 서로 통신합니다. 하지만 숫자로 이루어진 IP 주소를 기억하고 사용하는 것은 사용자에게 불편하기 때문에, DNS는 우리가 사용하는 도메인 이름(예: google.com)을 해당하는 IP 주소로 변환하여 컴퓨터가 이해할 수 있도록 도와줍니다.

 

DNS는 전화번호부와 비슷합니다.
도메인 이름은 사람의 이름(예: Google), IP 주소는 전화번호(예: 123-456-7890)입니다.
사람은 이름을 기억하고, 전화번호부를 통해 해당 이름에 맞는 번호를 찾습니다. DNS도 마찬가지로 도메인 이름을 입력하면 IP 주소를 반환합니다.

DNS의 동작 과정

DNS의 모든 쿼리(DNS 요청이라고도 함)는 동일한 논리에 따라 IP 주소를 확인합니다. 사용자가 URL을 입력하면 컴퓨터는 DNS 서버를 점진적으로 쿼리하여 사용자의 요청을 처리하는 데 적합한 정보 및 리소스 레코드를 찾습니다. 이 프로세스는 DNS가 해당 도메인과 연결된 권한 있는 DNS 서버에서 올바른 응답을 찾을 때까지 계속됩니다.

보다 구체적으로 DNS의 쿼리 확인에는 몇 가지 주요 프로세스 및 구성 요소가 포함됩니다.

 

1. 사용자가 example.com에 대한 DNS Query를 보냅니다.
2. Recursive DNS Resolver(재귀적 DNS 서버)가 Root DNS Server에 example.com에 대한 정보를 요청합니다.
3. Root DNS Server는 TLD(Top Level Domain) 네임서버 정보를 반환합니다.
4. Recursive DNS Resolver는 .com TLD Name Server에 다시 example.com에 대한 요청을 보냅니다.
5. .com TLD Name Server는 해당 도메인의 Authoritative Name Server( 권한 있는 이름 서버 ) 정보를 반환합니다.
6. Recursive DNS Resolver는 Authoritative DNS Resolver에 example.com에 대한 최종 요청을 보냅니다.
7. Authoritative DNS Resolver는 해당 도메인의 IP 주소(예: 192.0.0.16)를 반환합니다.
8. Recursive DNS Resolver는 IP 주소를 사용자에게 전달합니다.

이 과정을 통해 도메인 이름(예: example.com)이 실제 IP 주소로 변환되어 사용자는 해당 웹사이트에 접근할 수 있습니다.

 

DNS서버 유형

처음부터 개발자들은 빠르게 확장되는 컴퓨터 네트워크에 보조를 맞출 수 있는 도메인 이름 확인에 대한 보다 동적인 접근 방식을 용이하게 하기 위해 계층적 분산 데이터베이스 구조로 DNS를 설계했습니다. 계층 구조는 점(.)으로 표시된 루트 수준에서 시작하여 '.com', '.org', '.net'과 같은 최상위 도메인(TLD) 또는 '.uk' 및 '.jp'와 같은 국가 코드 TLD(ccTLD) 및 두 번째 수준 도메인으로 나뉩니다.

DNS 아키텍처는 두 가지 유형의 DNS 서버, 즉 재귀 서버와 권한 있는 서버로 구성됩니다. 재귀 DNS 서버는 사용자를 웹 사이트에 연결하는 정보를 검색하는 "요청"을 수행하는 서버입니다.

 

 

 

재귀적 DNS 리졸버

Recursive Resolver는 DNS 쿼리 프로세스에 관여하는 첫 번째 서버입니다. 이는 사용자 장치와 도메인 이름을 해결하는 데 필요한 다른 DNS 서버 사이의 중개자 역할을 합니다.

DNS 확인에서의 역할:

• 클라이언트 상호작용 : 브라우저에 도메인 이름(예: www.example.com)을 입력하면 요청이 먼저 재귀적 리졸버로 전송됩니다. 이는 일반적으로 인터넷 서비스 공급자(ISP) 또는 Google의 Public DNS(8.8.8.8)와 같은 공용 DNS 리졸버에서 제공합니다.
• 재귀적 쿼리 : 리졸버는 쿼리에 대한 답을 저장하지 않습니다. 따라서 클라이언트를 대신하여 계층 구조(루트, TLD 및 권한 있는)의 다른 DNS 서버에 연락하여 도메인의 올바른 IP 주소를 찾는 재귀적 쿼리를 수행합니다.
• DNS 캐싱 : 효율성을 높이고 조회 시간을 줄이기 위해 재귀적 리졸버는 DNS 쿼리 결과를 일정 기간 동안 캐시에 저장합니다. 이를 통해 동일한 도메인에 대한 향후 요청을 더 빠르게 해결할 수 있습니다.

루트 네임 서버

루트 네임 서버는 도메인 이름을 IP 주소로 변환하는 첫 번째 단계입니다. DNS 계층 구조의 맨 위에 위치하며 모든 도메인 이름 조회의 참조 지점입니다.

DNS 확인에서의 역할:

• 트래픽 지시 : 재귀적 리졸버가 DNS 쿼리를 받으면 먼저 루트 서버 중 하나에 연결합니다. 루트 서버는 요청된 도메인의 IP 주소를 모르지만, 다음에 어떤 최상위 도메인(TLD) 서버(예: .com, .net, .org)를 쿼리해야 하는지는 알고 있습니다.
• TLD 참조 : 루트 서버는 도메인 확장자에 따라 적절한 TLD 서버로 재귀적 확인자를 연결하여 응답합니다(예: example.com은 .com TLD 서버로 참조됨).

전 세계적으로 13개의 루트 네임 서버가 있으며, ICANN(Internet Corporation for Assigned Names and Numbers) 등의 기관이 관리합니다.

이러한 각 루트 서버는 높은 중복성을 갖추고 있으며, 전 세계에 많은 물리적 위치가 있어 안정성과 가용성을 보장합니다.

TLD 네임 서버

TLD(최상위 도메인) 이름 서버는 .com, .org, .net과 같은 특정 최상위 도메인 내의 도메인 이름에 대한 정보를 유지 관리하고 제공하는 DNS 서버입니다.

예를 들어, www.example.com 을 찾고 있다면 ".com"의 TLD 이름 서버는 "example.com"의 DNS 레코드를 보유한 권한 있는 DNS 서버를 찾는 데 도움이 됩니다. TLD 서버는 DNS 확인 프로세스에서 중요한 단계로, 쿼리가 올바르게 라우팅되도록 보장합니다.

DNS 확인에서의 역할:

• TLD별 쿼리 : 재귀적 확인자가 루트 서버에서 TLD 서버로 참조되면, 재귀적 확인자는 특정 도메인 이름의 레코드를 보관하는 권한 있는 DNS 서버의 IP 주소를 TLD 서버에 쿼리합니다.
• 도메인 디렉토리 유지 관리 : TLD 서버는 특정 TLD 내의 도메인에 대한 디렉토리를 포함하고 있으며, 특정 도메인을 확인하기 위해 어떤 권한 있는 네임 서버에 연락해야 하는지 나열합니다.

TLD의 종류:

1. 일반 TLD(gTLD) : .com, .net, .org와 같은 일반적인 확장자.
2. 국가 코드 TLD(ccTLD) : .us(미국), .uk(영국), .jp(일본)과 같은 국가별 확장자.
3. 후원 TLD(sTLD) : 교육 기관의 경우 .edu, 정부 기관의 경우 .gov와 같이 특정 커뮤니티나 조직의 후원을 받습니다.

권한 있는 이름 서버

Authoritative Name Server (권한 있는 이름 서버)는 DNS 쿼리에 대한 최종 답변을 제공하는 DNS 레코드를 보관합니다. DNS 조회 프로세스의 마지막 단계이며 해당 도메인에 대한 해당 IP 주소와 같은 특정 도메인에 대한 정보를 포함합니다.

DNS 확인에서의 역할:

• DNS 쿼리에 응답 : 재귀적 리졸버가 권한 있는 이름 서버에 도달하면 요청된 도메인 이름에 대한 IP 주소(또는 MX나 CNAME과 같은 다른 DNS 레코드)를 수신합니다.
• 호스팅 영역 파일 : 권한 있는 서버는 다음과 같은 DNS 레코드를 포함하는 "영역 파일"을 호스팅합니다.
  • A 레코드 : 도메인 이름을 IP 주소에 연결하여 웹사이트에 접속할 수 있게 합니다.
  • CNAME 레코드 : 한 도메인이 다른 도메인을 가리키도록 하여 별칭을 만듭니다.
  • MX 레코드 : 도메인의 이메일 수신을 담당하는 메일 서버를 지정합니다.
  • NS 레코드 : 도메인에 대한 권한이 있는 DNS 서버를 나타냅니다.

각 레코드를 자세히 알아보려면 DNS 레코드 블로그를 확인하세요 .

• 최종 해결 : 권한 있는 서버가 IP 주소를 제공하면 재귀적 해결자가 이 정보를 사용자 브라우저로 반환합니다. 그러면 브라우저가 웹 서버에 연결하여 웹사이트를 로드할 수 있습니다.

예:

www.example.com 도메인의 경우 권한 있는 이름 서버는 실제 IP 주소(예: 192.0.0.16 )를 가지고 있으며 이 정보를 재귀적 확인자로 다시 전송합니다.

권한 있는 네임 서버의 유형:

1. 기본(마스터) 이름 서버 : 이 서버에는 원본 영역 파일이 포함되어 있으며 DNS 레코드로 직접 업데이트할 수 있습니다.
2. 2차(슬레이브) 네임 서버 : 이 서버는 1차 서버로부터 영역 파일의 사본을 받고 백업 역할을 하여 높은 가용성과 중복성을 보장합니다.

DNS 캐싱 및 그 영향

DNS 서버는 종종 효율성을 개선하기 위해 이전 쿼리의 결과를 캐시합니다. 예를 들어, www.example.com을 방문하면 재귀적 리졸버는 DNS 레코드 의 TTL(Time-to-Live) 값에 따라 결정되는 지정된 기간 동안 IP 주소를 캐시에 저장합니다. 이 기간 동안 www.example.com에 대한 후속 쿼리는 캐시에서 해결되어 웹사이트에 액세스하는 데 걸리는 시간이 줄어듭니다.

DNS 캐싱의 이점:

• 응답 시간 향상 : 캐시된 레코드를 통해 반복되는 쿼리에 더 빠르게 응답할 수 있습니다.
• DNS 서버의 부하 감소 : 캐시된 응답을 제공함으로써 DNS 서버의 부하가 최소화됩니다.
• 네트워크 효율성 : 캐싱은 외부 DNS 조회 수를 줄여 네트워크 성능을 최적화합니다.

인터넷 사용에 있어서 DNS의 중요성

DNS는 인터넷의 기능에 필수적입니다. 그 이유는 다음과 같습니다.

1. 웹 탐색을 간소화합니다 . DNS는 사용자가 복잡한 IP 주소 대신 기억하기 쉬운 도메인 이름을 사용하여 웹사이트에 액세스할 수 있도록 합니다. 웹과 상호 작용하는 방식을 간소화합니다.
2. 확장성 : DNS의 계층 구조는 높은 확장성을 제공하여 전 세계적으로 수십억 개의 인터넷 연결 장치를 지원합니다.
3. 장애 내구성 : DNS는 장애 내구성을 염두에 두고 설계되었으며, 분산 네트워크에서 여러 DNS 서버를 사용하여 한 서버에 장애가 발생하더라도 다른 서버가 대신 수행할 수 있도록 보장합니다.
4. 효율성을 위한 캐싱 : DNS는 캐싱에 의존하여 해결 프로세스를 가속화합니다. 도메인이 해결되면 답변은 장치나 ISP에 로컬로 저장되어 향후 더 빠른 응답을 보장합니다.

DNS 보안

DNS는 인터넷 인프라의 기본 구성 요소이지만, 서비스를 중단시키거나 데이터 침해로 이어질 수 있는 다양한 공격에 취약합니다.

DNS 취약성은 인터넷 보안에 상당한 위험을 초래합니다. 도메인 이름 시스템은 인간 친화적인 도메인 이름을 기계가 읽을 수 있는 IP 주소로 변환하는 데 필수적입니다. 일반적인 취약성으로는 사용자를 악성 사이트로 리디렉션하는 DNS 스푸핑과 DNS 서버를 과부하시켜 서비스 중단을 일으키는 DDoS 공격이 있습니다.

이러한 위협에 대처하기 위해 DNSSEC 와 같은 DNS 보안 조치를 구현하면 DNS 응답의 무결성이 향상되고, 보안 DNS 리졸버를 사용하면 도청으로부터 보호하기 위해 쿼리가 암호화됩니다. 정기적인 모니터링, 영역 전송 제한, 사용자에게 피싱 위험에 대한 교육을 통해 DNS 보안이 더욱 강화되어 보다 안전한 온라인 환경이 보장됩니다.

 

 

3-way Handshake 

TCP 3-way Handshake 는 서버와 클라이언트 간에 안정적인 연결을 설정하기 위한 3단계 과정입니다. 이를 두 사람이 교환하는 악수와 비슷하게 생각할 수 있습니다. 한 사람이 손을 내밀고, 다른 사람이 손을 잡은 후 첫 번째 사람이 이를 인정하는 방식입니다. 이 과정은 연결을 안전하고 신뢰성 있게 만들어, 데이터가 정확하게 전달될 수 있도록 합니다.

3-way Handshake 과정

3-way Handshake는 동기화(SYN), 동기화-확인(SYN-ACK), 확인(ACK)의 세 단계로 구성됩니다. 각 단계에서 어떤 일이 일어나는지 살펴보겠습니다.

 

1. SYN: 시작 컴퓨터(클라이언트)는 서버에 SYN 패킷을 보냅니다. 이 패킷에는 임의의 시퀀스 번호(예: 100)가 포함되어 있으며, 이는 클라이언트가 연결을 시작하려는 요청을 나타냅니다. 이때 서버가 열려 있는지 확인하는 신호를 보냅니다.

 

2. SYN-ACK: 서버가 클라이언트의 요청을 받으면, 서버는 SYN-ACK 패킷을 클라이언트에게 보냅니다. 이 패킷에는 두 개의 값이 포함됩니다. 첫 번째는 서버가 생성한 SYN 번호(예: 200), 두 번째는 클라이언트의 SYN 번호에 1을 더한 ACK 번호(예: 101)입니다. 이로써 서버는 클라이언트의 연결 요청을 수락하는 것입니다.

 

3. ACK: 마지막으로, 클라이언트는 서버로 ACK 패킷을 보냅니다. 이 패킷은 서버의 SYN-ACK 패킷을 확인하는 메시지입니다. ACK 패킷에는 서버의 SYN 번호에 1을 더한 값(예: 201)이 포함되어 있습니다. 이 단계에서 연결이 확립되며, 데이터 전송을 시작할 수 있습니다.

 

3-way Handshake 의 목적

1. 연결의 신뢰성 확보
   3-way Handshake를 통해 서버와 클라이언트는 서로의 존재를 확인하고 연결을 시작할 수 있습니다. 이로 인해 데이터 전송 전에 안정적인 연결이 보장됩니다.
2. 연결 매개변수 확인
   각 장치는 시퀀스 번호와 ACK 번호를 사용하여 서로의 상태를 확인합니다. 이를 통해 데이터가 정확히 도달하도록 보장합니다.
3. 보안성 향상
   이 과정이 없으면, 악의적인 사용자가 연결을 시도할 수 있습니다. 3-way Handshake는 연결의 보안성을 높여 중간자 공격을 방지하고, 연결의 무결성을 보장합니다.적절한 동기화가 없으면 블랙햇 해커와 같은 악의적인 행위자가 취약한 시스템에 연결을 설정할 수 있습니다.
4. 데이터 흐름 제어
   각 장치는 데이터 전송을 시작하기 전에, 언제 데이터를 보내고 받을지 협조합니다. 이를 통해 효율적인 데이터 흐름을 제어할 수 있습니다.

 

이제 . 3-way Handshake를 거쳐 연결이 확립되었으니 HTTPS가 사용되는 경우, 브라우저와 서버는 SSL/TLS 프로토콜을 통해 안전한 통신을 설정해야합니다. 그래서 이 SSL/TLS 프로토콜은 뭘까?

 

SSL/TLS 프로토콜

SSL과 TLS 모두 서버, 애플리케이션, 사용자 및 시스템 간의 데이터를 암호화하는 통신 프로토콜입니다. 네트워크를 통해 연결된 두 당사자를 인증하므로 데이터를 안전하게 교환할 수 있습니다. Taher Elgamal이 SSL 개발을 주도했으며 1995년에 SSL 2.0을 공개적으로 출시했습니다. SSL의 용도는 월드 와이드 웹을 통한 통신을 안전하게 유지하는 것이었습니다. SSL이 다양한 반복을 거친 후 Tim Dierks와 Christopher Allen이 1999년에 SSL 3.0의 후속으로 TLS 1.0을 만들었습니다. 

 

TLS는 SSL의 직접적인 후속이며 이제 모든 버전의 SSL이 더 이상 사용되지 않습니다. 하지만 TLS 연결을 설명하는 데 SSL이라는 용어가 많이 사용됩니다. 대부분의 경우 SSL 및 SSL/TLS라는 용어 모두 TLS 프로토콜과 TLS 인증서를 나타냅니다.

 

TLS는 암호화 및 인증을 지원하는 보안 통신 프로토콜입니다. SSL이 더 이상 사용되지 않기 전에는 SSL이 이 역할을 했습니다. TLS와 SSL 모두 핸드셰이크 프로세스를 용이하게 하고 브라우저와 웹 서버 간에 암호화된 통신을 설정하는 디지털 인증서를 사용합니다. HTTPS에서 사용 HTTP는 네트워크를 통한 클라이언트와 서버 간 통신을 위한 통신 규칙 세트 또는 프로토콜입니다. HTTPS는 비보안 HTTP 연결에 보안 SSL/TLS 프로토콜을 설정하는 방법입니다. 웹 사이트에 연결하기 전에 브라우저는 TLS를 사용하여 웹 사이트의 TLS 또는 SSL 인증서를 확인합니다. TLS 및 SSL 인증서는 서버가 현재 보안 표준을 준수하고 있음을 보여줍니다. 브라우저 주소 표시줄에서 인증서에 대한 증거를 찾을 수 있습니다. 인증되고 암호화된 연결은 http:// 대신 https://를 표시합니다. 추가된 s는 secure, 즉 보안을 의미합니다.

주요 차이점: SSL과 TLS

SSL과 TLS의 용도는 매우 유사하지만 이들 통신 프로토콜은 작동 방식이 다릅니다. 이러한 변경 사항은 SSL이 TLS로 대체되기 전에 다양한 버전을 거치면서 시간이 지남에 따라 발전했습니다.

SSL/TLS 핸드셰이크

핸드셰이크는 브라우저가 서버의 SSL 또는 TLS 인증서를 인증하는 프로세스입니다. 이 프로세스는 양 당사자를 인증한 다음 암호화 키를 교환합니다.

SSL 핸드셰이크는 명시적 연결인 반면 TLS 핸드셰이크는 암시적 연결입니다. SSL 핸드셰이크 프로세스는 TLS 프로세스보다 단계가 더 많았습니다. TLS는 추가 단계를 제거하고 총 암호 그룹 수를 줄여서 프로세스 속도를 높였습니다. 

알림 메시지

SSL 및 TLS 프로토콜은 알림 메시지를 통해 오류와 경고를 전달합니다. SSL에는 경고와 치명적이라는 두 가지 알림 메시지 유형만 있습니다. 경고 알림은 오류가 발생했지만 연결을 계속할 수 있음을 나타냅니다. 치명적 알림은 연결을 즉시 종료해야 함을 나타냅니다. 또한 SSL 알림 메시지는 암호화되지 않습니다.

TLS에는 닫기 알림이라는 추가 알림 메시지 유형이 있습니다. 닫기 알림은 세션 종료를 알립니다. 또한 TLS 알림은 추가 보안을 위해 암호화됩니다.

메시지 인증

SSL과 TLS 모두 메시지의 진본성과 무결성을 확인하기 위한 암호화 기술인 메시지 인증 코드(MAC)를 사용합니다. 레코드 프로토콜은 보안 키를 사용하여 MAC을 고정 길이 코드로 생성하고 원본 메시지에 첨부합니다.

SSL 프로토콜은 MAC 생성에 MD5 알고리즘(현재는 구식)을 사용합니다. TLS는 더 복잡한 암호화와 보안에 해시 기반 메시지 인증 코드(HMAC)를 사용합니다. 

암호 그룹

암호 그룹은 브라우저와 서버 간의 정보를 암호화하기 위한 키를 생성하는 알고리즘 모음입니다. 일반적으로 암호 그룹에는 키 교환 알고리즘, 검증 알고리즘, 대량 암호화 알고리즘 및 MAC 알고리즘이 포함됩니다. 보안 문제로 인해 TLS의 여러 알고리즘이 SSL에서 업그레이드되었습니다.