HTTPS
HTTPS란?
https는 hypertext transfer protocol secure의 약자이며 HTTP의 보안버전 이다.
데이터 전송의 보안을 강화하기 위해 암호화를 한다.
은행 계좌, 로그인 및 개인 정보 등 중요한 데이터를 전송할 때 특히 중요하다.
HTTPS 사용 목적
HTTPS는 HTTP에서 '보안' 요소만 추가된 프로토콜이다. HTTPS의 주요 목적은 데이터의 무결성과 개인정보를 보호하는 것이다. 웹 브라우저와 웹 서버 간의 전송되는 모든 데이터가 암호화되어 가로채거나 변조되지 않는다.
추가적인 목적으로는 아래가 있다.
- 사용성: 크롬에서는 SSL 인증서가 없는 사이트를 방문시 Not secure 라는 경고창을 표시해준다.
- 사이트 체류시간 증가 : 체류시간에 증가할수록 seo의 이점이 있다. https가 적용되어 있지 않아 경고창이 보인다면 사용자의 사이트 체류시간 감소에 영향을 줄 수 있다.
💡 SEO(Search Engine Optimization, 검색 엔진 최적화)란?
검색 결과에서의 상위 노출을 의미한다.
- 사이트 로딩 속도 개선 : https는 https 보다 300% 이상 빠르게 로딩된다.
HTTP vs HTTPS Test
Encrypted websites protect our privacy and are significantly faster. Run this test and prepare to be amazed. #HttpsEverywhere
www.httpvshttps.com
- AMP(Accelerated Mobile Pages) 적용 : HTTPS에서만 적용 가능
💡 AMP(Accelerated Mobile Pages)란?
모바일 기기에서 컨텐츠를 훨씬 빠르게 로딩하기 위한 구글에서 만든 오픈소스 라이브러리
- 리퍼러(Referrer) 제공 : http는 Referral 정보가 제거되서 방문자들의 유입 경로를 파악하기 어렵다. (크롬 브라우저 85 이상 기준)
HTTPS 암호화 방식 (SSL/TLS)
HTTPS는 SSL/TLS 암호화 프로토콜을 통해 데이터를 암호화한다. SSL은 전송계층 바로 위에 위치한 Layer이다.
※ HTTP Message Body와 더불어 Http Header도 암호화 된다.
SSL(Secure Sockets Layer)은 Netscape사에서 1990년대 중반에 처음 나왔고 IETF라는 곳에서 개선 버전인 TLS(Transport Layer Security)가 1999년대에 등장했다.
대화나 마케팅에서 SSL 용어를 많이 사용하지만 오늘날 대부분의 보안 연결은 TLS를 사용한다.
해당 글에서 편의상 SSL로 통칭하겠다.
위 두 기관은 SSL를 무료로 발급해주는 서비스이다.
SSL은 공개키 방식과 대칭키 방식을 혼합해서 사용한다.
왜 두 방식을 함께 사용할까? 그전에 공개키 방식과 대칭키 방식에 대해 알아보자
대칭키 방식과 공개키 방식
대칭키 방식
동일한 키로 암호화와 복호화를 수행하는 방법
암복화화가 쉽다. 그러나 키가 노출되면 데이터 유실이 발생한다.
공개키 방식(=비대칭키)
서로 다른 키로 암호화와 복호화를 수행한다.
암호화 시에는 공개키를 사용하고 데이터 복호화 시에는 개인키를 사용한다.
공개키로 암호환 데이터는 오직 개인키로만 복호화할 수 있기 때문에 누구든지 공개키를 가져도 상관없다.
공개키는 노출되도 상관없다. 대칭키 방식보다 암호화 연산 시간이 더 소요되어 비용이 크다.
결론적으로, SSL은 각 방식이 가진 단점 때문에 두 방식을 모두 적절히 섞어 사용한다.
자세한 이유는 암호화 과정 내용 이후에 설명 하겠다.
SSL/ TLS 암호화 과정
사전 조건
- 서버에서 비대칭키 한쌍을 만듬
- 공개키를 들고서 공인된 인증기관을 찾아감
- 인증기관을 CA(Certificate Authority)라고 부름
- CA에 가서 인증서 생성을 요청함
- 도메인, 인증하는 사람 정보, 공개키를 알려줌
- 이러한 과정을 인증 서명 요청(CSR)이라고 함
- 인증기관은 검증 후 문제가 없다면 자신이 가지고 있는 개인키로 암호화 후 제공
- 이걸 인증서라고 봄, 개발자는 인증서를 서버에 올리고 ssl 설정을 함
- 인증기관에서 만든 공개키는 브라우저에 기본적으로 내장되어 있음
TCP handshake 과정이 끝나고 서버와 client간 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 통신이 끝났음을 서로에게 알려준다.
이 때 통신에서 사용한 대칭키인 세션키를 폐기한다.
공개키를 사용하면 될 것을 대칭키와 공개키를 조합해서 사용하는 이유는 무엇일까?
공개키 방식은 위에서 말했듯이 암호화 연산 시간이 더 소요되어 비용이 크다. 만약 많은 접속이 물리는 서버라면 매우 큰 비용을 지불해야 한다.
반대로 대칭키는 키가 노출되면 데이터 유실이 발생한다.
그래서 속도는 느리지만 데이터를 안전하게 주고 받을 수 있는 공개키 방식으로 대칭키를 암호화하고, 실제 데이터를 주고 받을 때는 대칭키를 이용해서 데이터를 주고 받는 것이다.
openssl (생략)
DNS
DNS 개념
Domain Name System의 약자로, 도메인 이름과 IP 주소에 대한 정보를 관리하는 시스템
사용자는 DNS를 통해 서버의 IP 주소를 몰라도 도메인 주소만을 이용해서 서버에 접근할 수 있다.
DNS 작동 방식
간단 버전
1. 브라우저 캐시에서 IP 있나 확인
2. 컴퓨터에 저장되어 있는 hosts 파일 확인
3. DNS 캐싱 확인
4. 없으면 DNS 서버에게 도메인에 대한 IP 주소 요청
하나의 서버에서 모든 DNS를 관리하지 않고 여러 서버로 분리해서 사용한다.
트래픽과 데이터를 분산함으로서, 안정적인 서비스를 제공
DNS는 도메인을 트리구조로 계층적이게 관리한다.
TLD 아래로는 서브 도메인이라 이야기 한다.
계층 구조에 따라 서버들이 배치가 되어있음
💡 Root DNS(루트 네임서버)란?
Root DNS는 인터넷의 도메인 네임 시스템의 루트 존이다.
ICANN이 직접 관리하는 절대 존엄 서버로, TLD DNS 서버 IP들을 저장해두고 안내하는 역할을 한다.
전세계에 961개의 루트 DNS가 운영되고 있다.
💡 TLD(Top-Level Domain, 최상위 도메인) DNS Server 란?
TLD는 도메인 등록 기관(Registry)이 관리하는 서버로, 도메인 네임의 가장 마지막 부분을 말한다.
예를들어 웹사이트에서 한번쯤은 봐왔던 '.com' 이나 'co.kr' 같은 도메인들을 관리하고 부여하는 서버이다. 💡 Authoritative(sub name) DNS 서버 주소를 저장해두고 안내하는 역할을 한다.
💡 Authoritative(=sub domain) DNS Server 란?
실제 개인 도메인과 IP 주소의 관계가 기록/저장/변경되는 서버.
그래서 권한의 의미인 Authoritative가 붙는다.
일반적으로 도메인/호스팅 업체의 ‘네임서버’를 말하지만, 개인이나 회사 DNS 서버 구축을 한 경우에도 여기에 해당하게 된다.
상위서버는 하위 서버들의 위치를 알고 있음
루트를 기반으로 아래로 내려가면서 원하는 도메인까지 도착
서버들은 다양한 기관에서 관리해줌
보통 도메인을 구매하는 기관은 서브 도메인 네임 서버임
서브 도메인 NS는 실제로 DNS 정보를 가지고 있어서 권한이 있는 네임서버
💡 Local DNS(기지국 DNS 서버) 란?
로컬 DNS 서버는 권한이 없는 네임서버
클라이언트와 직접적으로 통신을 해서 네임서버들과 통신을 하기 위한 중간 역할자 수행
기본적으로 인터넷을 사용하기 위해선 IP를 할당해주는 통신사(KT, SK, LG 등...)에 등록하게 된다.
컴퓨터의 LAN선을 통해 인터넷이 연결되면, 가입했던 각 통신사의 기지국 DNS 서버가 등록되게 된다.
그러니까 KT를 사용하는 집이면 KT DNS가 되고, SK통신사 사용하는 집이면 SK DNS가 자동으로 셋팅 된다.
종류: KT, LGU+, SKT, CJ헬로비전, Cloudflare 등등
클라이언트와 직접적으로 통신을 해서 네임서버들과 통신을 하기 위한 중간 역할자 수행
로컬 dns 서버는 힌트파일이라고 해서 루트 네임 서버에 접근하기 위한 정보가 있음
로컬 DNS 서버 -> Root Ns
IP 줘, 나는 없으니 하위 도메인 서버로 가봐
로컬 DNS 서버 -> TLD NS
IP 줘, 나도 없으니 서브 도메인 NS로 가봐
로컬 DNS 서버 -> 서브 도메인 NS
IP줘, 나는 있으니 IP 주소 줄께
로컬 DNS 서버가 전달받은 IP를 브라우저에 전달
DNS 과정 깊은 버전
1. 브라우저 캐시에서 IP 있나 확인
2. 컴퓨터에 저장되어 있는 hosts 파일 확인
3. 없으면 로컬 DNS에 IP 요청
4. 로컬 DNS의 캐싱정보를 확인 후 있으면 클라이언트에게 즉시 반환 없으면 Root DNS 서버에게 요청
5. Root DNS 서버에 IP 주소가 없다면 Local DNS 서버에게 다른 DNS 서버에게 물어봐라고 응답한다.
6. Local DNS 서버는 TLD DNS 서버에 IP 주소를 요청한다.
7. com 도메인을 관리하는 서버에도 해당 정보가 없으면 Local DNS 서버에게 다른 DNS 서버에게 물어봐라고 응답한다.
8. Local DNS 서버는 sub name DNS 서버에게 IP 주소를 요청한다.
9. IP 주소가 있으면 Local DNS 서버에게 IP 주소를 응답한다.
10. Local DNS 서버는 캐싱을 하고 IP 주소를 클라이언트에게 전달한다.
DNS 질의 종류
재귀적 질의 (Recursive Query)
DNS 서버는 클라이언트로 반환할 IP 주소가 있을 때까지 다른 DNS 서버에 계속 질의하는 방식
반복적 질의 (Iterative Query)
DNS 서버가 여러 DNS 서버에 차례대로 요청하여 IP를 찾는 질의 방식
💡 재귀적 질의와 반복적 질의 간단 예시
재귀적 질의
클라이언트는 DNS 확인자에게 "이봐요, 난 이 도메인의 IP 주소가 필요해요. 찾아보고 찾을 때까지 내게 연락하지 마세요"라고 이야기하는 셈
반복적 질의
클라이언트는 DNS 확인자에게 "이봐요, 난 이 도메인의 IP 주소가 필요해요. 조회 과정에서 다음 DNS 서버의 주소를 알려 주면 내가 직접 찾을 수 있어요."라고 이야기하는 셈
DNS 레코드 타입 종류
레코드의 타입이란 도메인 이름에 어떤 타입의 값이 매핑되는지를 나타낸다.
A
도메인 이름을 IP 주소로 매핑해준다.
CNAME
도메인 이름에 대한 별칭을 매핑해준다.
IP 주소가 변경될 경우 A 타입은 N개를 변경해야 하지만 CNAME 타입흔 하나만 변경하면 된다.(변경에 유연)
NS
권한이 있는 네임 서버를 매핑해준다.
다른 네임 서버에 도메인 이름에 대한 권한을 위임해 줄 수 있다.
GSLB와 CDN (생략)
UDP
UDP 개념
UDP란(User Datagram Protocol)란 전송계층에서 사용하는 프로토콜이다.
데이터그램 단위로 처리한다.
데이터의 신뢰성이 중요하지 않을때 사용한다.
3-way-handshake를 하지 않고 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠르다.
UDP 헤더
- Source Port : 데이터를 생성한 애플리케이션에서 사용하는 포트번호
- Destination Port : 목적지 애플리케이션이 사용하는 포트 번호
- Lenght : UDP헤더와 데이터를 합친 길이
- checksum : 중복 검사의 한 형태로, 오류 정정을 통해 공간(전자 통신)이나 시간(기억 장치) 속에서 송신된 자료의 무결성을 보호하는 단순한 방법. (TCP의 체크섬과는 다르게 UDP의 체크섬은 사용해도 되고 안해도 되는 옵션)
UDP 체크섬
UDP 체크섬이란 전송된 데이터의 값이 변경되었는지 검사하는 값이다.
무결성을 통해서 네트워크를 통해서 수신된 데이터에 오류가 없는지 여부를 확인한다.
송신자는 데이터를 기반으로 체크섬 값을 계산하고 이 값을 패킷과 함께 보낸다.
수신자는 송신자와 마찬가지로 수신된 데이터에 대한 체크섬을 계산하고 값이 일치하면 데이터가 손상되지 않은것으로 간주한다.
- 체크섬 계산시 pseudo-header(슈도 헤더)란 임시 헤더를 만들어 계산한다.
- 직접적인 전송에는 쓰이지 안혹, checksum 계산을 위해 사용한다.
- IP 헤더로 부터 출발지 IP 주소, 목적지 IP 주소, 프로토콜 종류를 가져오고 UDP Header로 부터 UDP 길이를 가져온다
❓ IP는 UDP 계층 보다 아래에 있는데 어떻게 IP를 알지..?
✔ chatgpt 4.0: 3계층에 존재하는 IP 주소가 전송 계층에 제공되어 UDP 체크섬 계산에 포함될 수 있다.
check sum 계산 과정
1. 도착 IP 주소, 송신 포트 번호, 수신 포트 번호, 데이터 길이, payload 등의 데이터들을 16비트 단위로 쪼개서 전부 더함
2. 더하는 도중 overflow 되서 carry-out된 값이 있다면 결과에 다시 더해서 sum 값을 만든다.
3. 계산한 sum 값을 1의 보수를 취하면 checksum값이 된다.
신뢰적 데이터 전송의 원리
전송 후 대기 프로토콜
Stop-and-wait protocol이라 부르며 네트워크를 통해 패킷을 전송하는데 사용되는 간단한 프로토콜이다.
송신자가 데이터를 전송하고 수신자로부터 응답을 받을 떄까지 기다리는 방식이다.
수신자는 전송 받은 프레임에 대해 확인(ACK) 또는 부정(NAK) 신호를 송신자에게 되돌려 준다.
송신자는 ACK 신호를 받으면 다음 패킷을 전송하고 NAK 신호를 받으면 같은 패킷을 재전송한다.
타임아웃이 발생해도 송신자는 패킷을 재전송한다.
장점
구현이 간단하다.
패킷이 순서대로 전송되고, 각 데이터에 대한 확인이 있기 때문에 패킷 손실이나 오류발생시 즉시 처리할 수 있다.
단점
순차적으로 전송하기 때문에 지연 시간이 발생할 수 있어 전체적으로 효율성이 떨어진다.
파이프라인 프로토콜
파이프 라인을 여러 작업을 동시에 처리하거나 동시에 여러 단계를 진행하는 기술을 일컫는다.
한번에 여러 패킷을 보낼 수 있도록 하여 네트워크의 사용률을 높이고 효율성을 향상시킨 프로토콜 방식이다.
대표적으로 아래 두가지 프로토콜이 있다.
- Go-Back-N
- Selective repeat
- Piggy Backing 방식
Go-Back-N(GBN)은 수신자측에서 순서대로 받지 못한 패킷이 있다면 해당 패킷부터 다시 재전송 하는 방식이다.
단점은 패킷 하나가 오류가 발생하면 정상 전송된 패킷이라도 버리고 잘못된 패킷부터 다시 재전송 된다. 이유는 패킷 순서가 꼬이지 않게 할려고 하기 위함이다.
Selective Repeat(SR)은 수신자측에서 받은 각각의 패킷들에 대해 ACK을 보내는 방식이다.
ACK를 받지 않은 패킷은 손실된 패킷으로 간주하고 해당 패킷만 재전송한다.
정상 패킷은 버리지 않고 버퍼에 저장 해둔다.
Piggy Backing 방식은 송신자에서 정보 프레임을 전송하면서 응답 프레임을 같이 수행할 수 있도록 프레임 구조를 재정의하여 양방향으로 전송하는 방식이다.
응답 프레임의 전송 횟수를 줄여 전송 효율을 높일 수 있다.
참고
https
https://www.cloudflare.com/ko-kr/learning/ssl/what-is-https/
https://www.ascentkorea.com/difference-between-http-and-https/
https://www.youtube.com/watch?v=wPdH7lJ8jf0
https://parksb.github.io/article/24.html
https://www.ssl.com/ko/%EC%9E%90%EC%A3%BC-%EB%AC%BB%EB%8A%94-%EC%A7%88%EB%AC%B8/https-%EB%9E%80/
dns
https://www.youtube.com/watch?v=sDXcLyrn6gU
https://www.cloudflare.com/ko-kr/learning/dns/what-is-recursive-dns/
udp
https://www.youtube.com/watch?v=ikDVGYp5dhg
https://limjunho.github.io/2021/06/05/UDP-cksum.html
https://code-lab1.tistory.com/25
https://lordofkangs.tistory.com/58
https://junboom.tistory.com/22
'외부활동 > CS 면접 끝장내기 - 컴퓨터 네트워크 2기' 카테고리의 다른 글
| 컴퓨터 네트워크 5주차 스터디 정리 (2) | 2023.08.20 |
|---|---|
| 컴퓨터 네트워크 4주차 스터디 정리 (0) | 2023.08.13 |
| 컴퓨터 네트워크 3주차 스터디 정리 (0) | 2023.08.07 |
| 컴퓨터 네트워크 1주차 스터디 정리 (0) | 2023.07.23 |
댓글