[컴퓨터 네트워크 스터디 2주차] HTTPS , DNS , UDP , 신뢰적 데이터 전송

HTTPS

 

HTTPS  란 ?

 

HTTPS(Hypertext Transfer Porotocol Secure) 는 웹 브라우저와 웹 사이트 간에 데이터를 전송하는 데 사용되는 기본 프로토콜인 HTTP의 보안 버전입니다. HTTPS는 데이터 전송의 보안을 강화하기 위해 암호화 된다. 이는 사용자가 은행 계좌, 이메일 서비스, 의료 보험 공급자에 로그인 하는 등 중요한 데이터를 전송할 때 특히 중요하게 사용된다. 즉 HTTP 요청과 응답을 암호화 하기 위해 TLS또는 SSL 기반 HTTP라고 할 수 있다.

 

 

SSL / TLS 란 ?

 

원래 웹에서의 데이터는 가로채면 누구나 읽을 수 있는 일반 텍스트 형대로 전송 되었다. 이러한 문제때문에 인터넷 통신의 개인정보 보호 , 인증 , 데이터 무결성을 보장하기 위해 Netscape가 1995년 처음으로 SSL을 개발하였다.

 

SSL(Secure Sockets Layer)은 암호화 기반 인터넷 보안 프로토콜이다. 전달되는 모든 데이터를 암호화하고 특정한 유형의 사이버 공격도 차단한다. SSL은 TLS 암호화의 전신이기도 하다. 

 

SSL은 알려진 취약성이 여러가지 있으면 보안 전문가들은 SSL 사용 중단을 권장한다고 한다. 그 대안으로는 앞에서 언급한 TLS가 있다.

TLS는 최신 암호화 프로토콜로 , SSL 암호화로 혼용해서 부르는 경우도 많다. 실제로 현재 SSL을 인증한 업체 및 제공하는 업체는 사실상 TLS 암호화를 제공하고 있는 것이다. 결과적으로 TLS는 SSL의 업데이트 버전이며 명칭만 다르다고 볼 수 있다.

 

암호화 ( 대칭키  &  비대칭키)

 

TLS는 대칭키와 비대칭키(공개키) 둘 다 사용해서 데이터를 암호화합니다.

 

 

대칭키

 

위 사진과 같이 데이터를 암호화/복호화 할 때 사용하는 key 가 같은것을 대칭키 암호화 방식이라고 부른다.

암복호화가 쉽지만 키가 노출되면 데이터 유실이 발생하기도 쉽다.

 

비대칭키(=공개키)

 

비대칭키(공개키)는 암호화 / 복호화 할 때 사용되는 키가 다른 방식을 말한다.

이 공개키 알고리즘은 공개키로 암호화 하냐 , 개인키로 암호화 하냐에 따라 사용분야가 달라진다. 

 

공개키로 암호화를 하면 데이터 보안에 중점을 두고,

개인키로 암호화를 하면 인증 과정에 중점을 두는 것이다.

 

공개키로 암호화 한 데이터는 오직 개인키로만 복호화 될 수 있기 때문에 누구든지 공개키를 가져가도 상관이 없으며 공개키는 노출되도 상관없다. 대칭키 방식보다 암호화 연산 시간이 더 소요되어 비용이 크다.

 

결론적으로 SSL/TLS은 각 방식이 가진 단점때문에 속도는 느리지만 데이터를 안전하게 주고 받을 수 있는 공개키 방식으로 대칭키를 암호화하고 , 실제 데이터를 주고 받을 때는 대칭키를 이용해서 데이터를 주고 받는 것이다.

 

SSL  /  TLS   암호화  과정  

 

사전 조건

• 서버에서 비대칭키 한쌍을 만든다.
• 공개키를 들고서 공인된 인증기관을 찾아간다.
  • 공인된 인증기관을 CA(Certificate Authority)라고 부른다.
• CA에 가서 인증서 생성을 요청한다.
  • 도메인 , 인증하는 사람 정보 , 공개키를 알려준다.
  • 이러한 과정을 인증 서명 요청(CSR)이라고 한다.
• 인증기관은 검증 후 문제가 없다면 자신이 가지고 있는 개인키로 암호화 후 제공
  • 이걸 인증서라고 보며 , 개발자는 제공 받은 인증서를 서버에 올리고 SSL/TLS 설정을 한다.
  • 인증기관에서 만든 공개키는 브라우저에 기본적으로 내장되어 있다.

 

TCP handshake 과정이 끝나고 서버와 clinet간 connection이 수립 된 이후에 SSL handshake를 하게 된다.

 

1. Client의 hello message

클라이언트가 서버에게 인증서를 요청하면서 생성한 랜덤값(client random)을 전송한다.

 

2. 서버의 hello message

서버는 인증서와 함께 생성한 랜덤값(server random)을 전송한다.

 

3. 클라이언트에서 인증서 확인

클라이언트 브라우저는 인증서의 인증기관을 확인 한 후 인증기관에서 제공한 공개키로 복호화를 한다. 

+ 복호화를 하면 해당 서버에서 만든 공개키를 꺼내서 사용할 수 있다.

클라이언트는 클라이언트에서 생성한 랜덤값 + 서버에서 생성한 랜덤 값을 조합해서 pre-master-secret 값을 생성한뒤 , 해당 서버에서 보낸 공개키를 이용해 pre-master-secret 값을 암호화하여 서버에 전송한다.

+pre-master-secret 값으로 최종적으로 통신에 사용할 대칭키를 만들기 때문에 제 3자에게 절대로 노출되어서는 안된다.

 

4. 서버는 개인키로 pre-master-secret를 복호화 한다.

클라이언트와 서버 모두 pre-master-secret 값을 공유하게 되었다.

서버와 클라이언트는 pre-master-secret 값을 바탕으로 master secret를 만든다. master secret를 바탕으로 session 키라는 대칭키를 만들어서 실제로 주고 받는 데이터를 암호화 하여 데이터 통신을 한다.

 

5. 데이터의 전송이 끝나면 SSL/TLS 통신이 끝났음을 서로에게 알려준다.

이 때 통신에서 사용한 대칭키인 세션키를 폐기한다.

 

속도는 느리지만 데이터를 안전하게 주고 받을 수 있는 공개키 방식으로 대칭키를 암호화하고 , 실제 데이터를 주고 받을 때는 대칭키를 이용해서 데이터를 주고 받는 것이다.

 

 

 DNS

 

 

DNS 란 ?

 

Domain Name System의 약자로, 도메인 이름과 IP 주소에 대한 정보를 관리하는 시스템이며 상위 기관과 하위 기관과 같은 "계층 구조를"가지는 분산 데이터베이스 구조이다.

실생활을 예로 들자면 인터넷 전화번호부라고 할 수 있다. 왜냐하면 다른 사람의 전화번호를 사용자가 자기가 알기 쉬운 이름으로 저장하여 사용하는 것처럼 사용자는 DNS를 통해 서버의 IP 주소를 몰라도 도메인 주소만을 이용해서 서버에 접근할 수 있다.

 

DNS 구성 요소

 

DNS 는 세 가지 요소로 구성되어 있다.

1. 도메인 네임 스페이스(Domain Name Space)
2. 네임 서버(Name Server) = 권한 있는 DNS 서버
3. 리졸버(Resolver , = 로컬DNS서버) = 권한 없는 DNS 서버

• 우선 "이 도메인 이름은 이 IP 주소이다"라는 정보를 저장하는 데이터베이스가 필요하다.
• 그리고 분산된 데이터가 어디 저장되어 있는지 찾을 프로그램들이 필요하고 찾았으면 해당 IP 주소로 이동할 프로그램(브라우저 등)이 필요하다.
• 도메인 네임 스페이스라는 규칙(방법)으로 도메인 이름 저장을 분산한다.
• 네임 서버(DNS 서버와 같은 말, 그런데 리졸버 서버 등 시스템 안에서 다른 역할을 하는 서버도 있기에 그냥 DNS 서버라고 하는 것보다 네임 서버라고 하는 게 더 의미가 전달된다고 한다)가 해당 도메인 이름의 IP 주소를 찾는다.
• 리졸버가 DNS 클라이언트 요청을 네임 서버로 전달하고 찾은 정보를 클라이언트에게 제공하는 기능을 수행한다.
• 어떤 네임 서버에서 찾아야 하는지 , 이미 캐시 되어있는지 등 어떻게든 찾아서 클라이언트에게 찾았으면 찾은 것을 못 찾았으면 못 찾았다고 전달하는 역할을 한다.
• 리졸버는 단말에 구현하는 것은 무리수라 보통은 리졸버가 구현된 네임 서버의 IP 주소만을 파악한다.
• 리졸버라는 요소를 생략하기도 하는 곳도 많다고 한다.

이렇게 구성되는 이유

• "이 도메인 좀 IP 주소로 바꿔줄래?"라고 할 수 있는 서버(네임서버)가 한 대만 있지 않기 때문이다.
• 그렇다면 여러 서버(네임서버)를 만들면 되지 않을까? 그렇게 되면 해당 정보(도메인과 IP 주소)를 모든 서버에서 공유해야 한다.
• 그래서 도메인을 계층적으로 구분하는 , 정보(도메인 과 IP주소)를 분산하는 구조를 선택하게 되었다.
• 그래서 도메인에 닷(dot), 점이 있는 것이다. 점이 계층을 표현해준다.

DNS  동작  방식  설명

 

DNS 동작 방식은 아래와 같은 순서로 구현된다.

• 웹 브라우저는 해결사 서버에게 요청한다.
  • "www.manseok.kr의 IP 주소를 알려주세요."
• 해결사 서버는 최상위 기관에서 관리하는  네임 서버에게 요청한다.
  • ".kr이라는 도메인 있나요?"
• 최상위 기관에서 관리하는 네임 서버는 응답한다.
  • ".kr 한국 국가 도메인 입니다. kr 네임 서버로 가보세요"
• 해결사 서버는 이제는 .kr 네임 서버에게 요청한다.
  • "manseok.kr"있나요?
• .kr 네임 서버는 응답한다.
  • "네 가비아로 가세요~"
• 해결사 서버는 가비아 네임 서버에게 요청한다.
  • "www.manseok.kr"있나요?
• 가비아 네임 서버는 응답한다.
  • "네 12.345.678.999 로 가세요!"
• 해결사 서버는 웹 브라우저에게 알려준다.
  • "네 12.345.678.999 로 가세요!"

 

DNS  질의  종류

 

 

 DNS Query란?

• DNS 클라이언트와 DNS 서버는 DNS 쿼리를 교환한다.
• DNS 쿼리는 Recursive(재귀적) 또는 Iterative(반복적)으로 구분된다.
• 아래의 용어가 위 동작 과정에 이해를 방해할 수도 있기에 추가하였다.
• 단순한 개념으로 아래와 같은 방식으로 요청과 응답을 한다고 이해하자.

 

 Recursive  Query(재귀적 질의)

 

DNS 서버는 클라이언트로 반환할 IP 주소가 있을 때까지 다른 DNS 서버에 계속 질의하는 방식

 

 Iterative  Query(반복적  질의)

 

DNS 서버가 여러 DNS 서버에 차례대로 요청하여 IP를 찾는 질의 방식

 

 

재귀적 질의와 반복적 질의 예시

 

재귀적 질의

클라이언트는 DNS 서버에게 "이봐요 , 난 이 도메인의 IP주소가 필요해요. 찾아보고 찾을 때까지 내게 연락하지 마세요"라고 이야기하는 방식

 

반복적 질의

클라이언트는 DNS 서버에게 "이봐요, 난 이 도메인의 IP 주소가 필요해요. 조회 과정에서 다음 DNS 서버의 주소를 알려주면 내가 직접 찾을 수 있어요. "라고 이야기하는 방식이다.

 

 

DNS  레코드가  무엇인가?

 

DNS 레코드는 기본적으로 각 도메인에 연결되어 있는 IP 주소와 각 도메인에 전송된 요청을 어떻게 처리할 지를 DNS 서버에 알려주는 역할을 합니다. DNS 서버는 요청을 실행하기 위해 명령어로서 여러가지 문자열을 사용하는데, 이때 사용되는 명령 문자열들을 DNS 문법이라고 합니다. DNS 레코드 문법의 종류에는 A , AAAA , CNAME , MX , PTR , NS , SOA , SRV , TXT , NAPTR 등이 있다. 이중 많이 사용되는 DNS 레코드 몇개를 정리해보자

• A & AAAA : 구매한 도메인이 가리키는 IP 주소를 설정하는 레코드입니다. IPv4는 A, IPv6는 AAAA를 사용합니다.
  이 레코드를 설정함으로써 인터넷 사용자가 웹 브라우저에 도메인 입력 시 설정된 IP 주소로 연결됩니다.
• CNAME : 주 도메인명 외에 보조 도메인명을 지정하는 레코드이다.
• MX : Mail Exchanger 레코드를 의미하며, MX 레코드가 DNS에 설정되어 있어야 도메인과 메일 서버가 연결되어 xxx@manseok.com 형식의 이메일 주소 이용이 가능하다.
• NS : 어떤 DNS 서버가 해당 도메인에 대한 권리를 가지고 있는지 가리키는 레코드이다.

 

DNS 서버에게 IP  주소를  요청할  떄 ,  왜  UDP를  사용하나?

 

• 빠른 속도
  • TCP의 경우 데이터 전송 시작 전에 3-way-handshaking 과정이 있는 반면 UDP는 연결 설정에 드는 비용이 없다. DNS는 신뢰성보다 속도가 더 중요한 서비스이기 때문에 TCP보다 UDP가 더 적합하다.
  • 또한, UDP는 512 bytes를 넘어가지 않는 패킷만 전송이 가능하고 오버헤드가 없어서 속도가 빠른데, DNS가 전송하는 데이터 패킷 사이즈가 매우 작으므로 UDP가 유리하다.
  • 이때 단순히 패킷의 사이즈가 작다고 DNS가 UDP를 채택한 것은 아니고, 전달하는 패킷의 크기가 작기 때문에 신뢰성이 보장되지 않아도 되기 때문이다. (못 받으면 다시 전달하면 된다.)
• 연결 상태를 유지할 필요가 없다.
  • 위에서 잠깐 언급했듯이 TCP는 호스트 간의 연결 상태를 유지한다. 이때 TCP의 패킷 안에는 여러 정보가 담겨 있지만, UDP는 어떤 정보도 기록하지 않고, 유지할 필요도 없다.
  • 따라서 DNS 서버는 TCP보다 많은 클라이언트를 수용할 수 있으므로 연결 상태를 유지하지 않고 정보 기록을 최소화할 수 있는 UDP를 채택하였다.

 

 

 UDP

 

UDP 란 ?

 

UDP란 비연결성 과 신뢰성이 없다는 특징을 가지고 있는 전송 계층에 포함되어 있는 프로토콜이다. TCP와는 다르게 3-way-handsdhake 과정을 거치지 않기 때문에 데이터 전달 및 순서가 보장되지 않지만 단순하고 속도가 빠르다.

데이터 그램 방식을 제공한다.

데이터그램 방식

데이터그램 방식은 데이터 전송 전에 송/수신자 사이에 가상 회선이라 불리는 논리적 경로를 설정하지 않고 , 패킷들이 각기 독립적으로 전송되는 방식을 말한다.

(주로 OSI7계층 중 네트워크 계층에서 사용)

 

UDP 장 / 단점

 

• 장점
  • 전송속도가 빠르다.
  • 패킷 오버헤드가 적어 네트워크 부하가 감소한다.
• 단점
  • 데이터의 신뢰성이 없다.
  • 오류가 발생한 패킷을 버릴 뿐 그 오류를 고치지 않기 때문에 패킷이 두번 전달 되거나 전달되지 않는 경우도 생길 수 있다. 또한 순서대로 전송되지 않을 수도 있다.

 

UDP  체크섬(checksum)

 

체크섬이란 네트워크를 통해서 전송된 데이터의 값이 변경되었는지(무결성)를 검사하는 값으로, 네트워크를 통해서 수신된 데이터에 오류가 없는지 여부를 확인한다.

 

송신자는 데이터를 기반으로 체크섬 값을 계산하고 이 값을 패킷과 함께 보낸다.

수신자는 송신자와 마찬가지로 수신된 데이터에 대한 체크섬을 계산하고 값이 일치하면 데이터가 손상되지 않은것으로 간주한다.

 

출처 - https://dncjf64.tistory.com/433

 

• 체크섬 계산시 pseudo-header(수도 헤더)란 임시 헤더를 만들어 계산한다.
• 직접적인 전송에는 쓰이지 않고 checksum 계산을 위해 사용한다.
• IP 헤더로부터 출발지 IP 주소 , 목적지 IP 주소 , 프로토콜 종류를 가져오고 UDP Header로 부터 UDP 길이를 가져온다.

check sum 계산 과정

1. 도착 IP 주소 , 송신 포트 번호 , 수신 포트 번호 , 데이터 길이 , payload 등의 데이터들을 16비트 단위로 쪼개서 전부 더한다.
2. 더하는 도중 overflow 되서 carry-out된 값이 있다면 결과에 다시 더해서 sum 값을 만든다.
3. 계산한 sum 값을 1의 보수 연산을 취하면 checksum값이 된다.

신뢰적 데이터 전송의 원리(전송 후 대기 프로토콜 , 파이프라인 프로토콜)

 

전송  후  대기  프로토콜

 

전송 후 대기 프로토콜(Stop-and-Wait Protocol)은 네트워크를 통해 패킷을 전송하는데 사용되는 간단한 프로토콜이다.

이 프로토콜은 송신자가 한 개의 패`을 전송하고 , 수신자로부터 응답을 받을 때까지 기다리는 방식으로 동작한다.

수신자는 전송 받은 패킷에 대해 확인(ACK) 또는 부정(NAK) 신호를 송신자에게 응답합니다. 송신자는 ACK 신호를 받으면 다음 패킷을 전송하고 , NAK 신호를 받으면 같은 패을 재전송합니다.  타임아웃이 발생해도 송신자는 패킷을 재전송한다.

 

• 장점
  
  • 구현이 간단하다. 
  • 패킷이 순서대로 전송되고 , 각 데이터에 대한 확인이 있기 때문에 패킷 손실이나 오류발생시 즉시 처리할 수 있다.

 

• 단점
  • 순차적으로 전송하기 때문에 지연 시간이 발생할 수 있어 전체적으로 효율성이 떨어진다.

 

파이프라인  프로토콜이  무엇인가?

 

파이프라인 프로토콜이란 파이프 라인을 여러 작업을 동시에 처리하거나 여러 단계를 진행하는 기술을 일컫는다.

한번에 여러 패킷을 보낼 수 있도록 하여 네트워크 사용률을 높이고 효율성을 향상시켜주는 프로토콜이다.

 

대표적으로 3가지 방식이 있다.

• Go - Back - N
• Selective repeat
• Piggy Backing 방식

Go - Back - N은 수신자측에서 순서대로 받지 못한 패킷이 있다면 해당 패킷부터 다시 재전송 하는 방식이다.

단점으로 패킷 하나가 오류가 발생하면 정상 전송된 패킷이여도 버리고 잘못된 패킷부터 다시 재전송 된다.
이유는 패킷 순서가 꼬이지 않기 위해서이다.

 

Selective Repeat(SR)은 수신자측에서 받은 각각의 패킷들에 대해   ACK을 보내는 방식이다.

ACK를 받지 않은 패킷은 손실된 패킷으로 간주하고 해당 패킷만 재전송한다.

정상 패킷은 버리지 않고 버퍼에 저장 해둔다.

 

Piggy Backing 방식은 송신자에서 정보 프레임을 전송하면서 응답 프레임을 같이 수행할 수 있도록 프레임 구조를 재정의하여 양방향으로 전송하는 방식이다. 응답 프레임의 전송 횟수를 줄여 전송 효율을 높일 수 있다.

 

 

 

 

 

참고 - https://hanamon.kr/dns%EB%9E%80-%EB%8F%84%EB%A9%94%EC%9D%B8-%EB%84%A4%EC%9E%84-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EA%B0%9C%EB%85%90%EB%B6%80%ED%84%B0-%EC%9E%91%EB%8F%99-%EB%B0%A9%EC%8B%9D%EA%B9%8C%EC%A7%80/