본문 바로가기
개발일기/설계와디자인

HTTPS 완벽 가이드 (평범한 엔지니어를 위한 친절한 설명)

by Daniel_Kevin 2024. 7. 29.
반응형

평범한 엔지니어로서 저는 인터넷과 HTTPS 통신을 당연하게 여겼고 더 깊이 파고들지 않았습니다. 오늘은 엔지니어로서 발전하고 인터넷 통신이 어떻게 작동하는지에 대한 대략적인 개요를 배우고 있으며, 특히 HTTP와 TLS에 초점을 맞추고 있습니다.

 

인터넷은 "단지" 상호 연결된 컴퓨터 네트워크의 네트워크입니다. "인터넷"이라는 용어는 문자 그대로 "네트워크 사이"를 의미합니다. 이는 패킷 교환 메시 네트워크 로 작동하며, 최선의 전달을 사용하므로 패킷이 전달될지 여부나 걸리는 시간에 대한 보장이 없습니다.

 

인터넷이 (적어도 기술적 관점에서) 매우 원활하게 작동하는 것처럼 보이는 이유는 재시도, 주문, 중복 제거, 보안 및 그 밖의 많은 것들을 백그라운드에서 처리하는 추상화 계층 때문입니다. 개발자가 애플리케이션 계층(일명 샌프란시스코에서 1년에 30만 달러에 HTTP 요청 작성)에만 집중할 수 있도록 합니다.

 

각 계층은 특정 기능을 제공하며, 이는 다른 프로토콜 에 의해 충족될 수 있습니다 . 이러한 모듈화를 통해 다른 계층의 프로토콜에 영향을 미치지 않고 한 계층의 프로토콜을 대체할 수 있습니다.

 

다음은 계층에 대한 간단한 표입니다.

이름
설명
커뮤니케이션 단위
고유 식별자
예
응용 프로그램 계층
애플리케이션별 논리를 관리합니다
메시지
응용 프로그램별
HTTP
보안 계층
암호화 및 인증을 제공합니다
기록
공개키 인증서
번역:
전송 계층
안정적인 데이터 전송을 보장합니다
세그먼트(TCP) / 데이터그램(UDP)
포트 번호
티에스테르
네트워크 계층
인터넷을 통해 패킷을 라우팅합니다.
패킷
IP 주소
아이피(IP)
링크 계층
물리적 매체를 관리합니다
프레임
MAC 주소
와이파이
물리 계층
한 장치에서 다른 장치로 원시 비트를 물리적으로 전송합니다.
비트
없음
광섬유, 이더넷 케이블

이러한 계층에 대해 더 자세히 살펴보겠지만, 먼저 이것이 실제로 어떻게 동작하는지 살펴보겠습니다.

 

HTTP 요청의 수명 주기

이러한 계층을 통한 HTTP 요청의 경로는 다음과 같습니다(간결성을 위해 물리적 계층은 건너뜁니다).

HTTP 요청의 수명 주기

 

 

300x250

 

1. 발신자가 요청을 합니다.

프로세스는 클라이언트(일반적으로 웹 브라우저)가 HTTP 요청을 구성하는 애플리케이션 계층에서 시작됩니다. HTTP는 텍스트 기반 프로토콜이므로 모든 데이터가 와이어를 통해 일반 텍스트로 전송됩니다.

 

첫 번째 줄에는 일반적으로 다음이 포함됩니다.

  • HTTP 메서드 (GET, POST 등)
  • 요청된 리소스 (예: /index.html)
  • 프로토콜 버전.

 

나머지 HTTP 메시지에는 헤더 key: value와 선택적 메시지 본문 형식이 포함되어 있습니다.

 

예: HTTP 요청

복사 
GET /index.html HTTP/1.1
Host: www.example.com
Accept: text/html
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36

2. DNS 조회 :

도메인 이름 시스템(DNS)은 사람이 읽을 수 있는 도메인 이름( www.example.com)을 IP 주소(예: 93.184.216.34)로 변환합니다. 클라이언트는 DNS 서버를 쿼리하여 도메인 이름을 해당 IP 주소로 확인합니다. 이 프로세스는 여러 개의 리졸버를 거쳐 도메인 이름을 IP 주소로 변환하는 권한 있는 서버에 도달합니다. 매우 높은 수준에서 세 가지 구성 요소는 다음과 같습니다.

 

  • 클라이언트 머신에 상주하며 요청을 적절한 재귀적 리졸버(다음에 설명)로 라우팅하는 스텁 리졸버
  • 재귀적 리졸버는 스텁 리졸버로부터 요청을 받고 권한 있는 서버에 쿼리하여 도메인 이름을 확인합니다. 종종 결과를 캐싱합니다. 인터넷 서비스 공급자(ISP)는 일반적으로 재귀적 리졸버를 제공하거나 Google DNS(8.8.8.8)와 같은 공개 리졸버를 사용할 수 있습니다.
  • 도메인에 대한 실제 DNS 레코드(예: A, MX, CNAME 등)를 포함하고 해당 레코드의 정보로 쿼리에 응답하는 권한 있는 서버 입니다. 권한 있는 서버는 도메인 이름 데이터에 대한 최종 진실의 원천입니다.

 

클라이언트가 도메인 이름을 사용하여 리소스에 대한 요청을 발행하면 컴퓨터의 스텁 리졸버가 재귀적 리졸버에 쿼리를 보내 도메인 이름을 확인합니다.

재귀적 확인자는 필요에 따라 권한 있는 DNS 서버에 쿼리를 보내 도메인 이름을 IP 주소로 확인합니다.

 

3. TCP 핸드셰이크 :

이제 서버의 IP 주소를 얻었으므로 클라이언트는 HTTP를 전송하기 시작할 수 있으며 전송 계층으로 이동합니다. 전송 계층에는 TCP(전송 제어 프로토콜)와 UDP(사용자 데이터그램 프로토콜)라는 두 가지 주요 프로토콜이 있습니다.

💡
TCP는 애플리케이션 간의 안정적이고, 순서대로, 오류가 검사된 데이터 전달을 보장하는 연결 지향 프로토콜입니다.

UDP는 전달, 순서 또는 오류 검사를 보장하지 않고 빠르고 오버헤드가 낮은 데이터 전송을 제공하는 연결 없는 프로토콜입니다.

 

2024년 현재 TCP는 인터넷에서 데이터 전송을 관리하는 주요 프로토콜인 반면 UDP는 덜 일반적으로 사용되며, 일반적으로 스트리밍이나 화상 통화와 같은 실시간 애플리케이션에서 낮은 지연 시간이 중요하고 가끔 패킷 손실이 허용됩니다. 이제 주제로 돌아갑니다.

클라이언트가 IP 주소를 얻으면 포트 80(HTTP의 표준 포트)에서 서버와 TCP 연결을 시작합니다. 여기에는 3단계 핸드셰이크가 포함됩니다.

  • SYN : 클라이언트가 서버에 SYN(동기화) 패킷을 보내 연결을 요청합니다.
  • SYN-ACK : 서버는 SYN-ACK(동기화-확인) 패킷으로 요청을 확인합니다.
  • ACK : 클라이언트가 서버로 ACK(확인) 패킷을 보내서 안정적인 연결을 설정합니다.

 

반응형

 

4. HTTP 요청 전송

TCP 연결이 이루어지면 클라이언트는 실제 HTTP 요청을 보냅니다. 언급했듯이 HTTP는 텍스트 기반 프로토콜이므로 요청 헤더와 본문(있는 경우)은 일반 텍스트로 전송됩니다.

 

5. 인터넷을 통해 서버로 라우팅된 패킷

⚠️⚠️⚠️⚠️⚠️ 여기서 깊이 들어가보겠습니다 ⚠️⚠️⚠️⚠️⚠️

클라이언트가 요청을 보내면 데이터 패킷은 서버로 직접 이동하지 않습니다. 대신 다양한 네트워크 장치, 주로 라우터를 통과하는 경로를 따라가는데, 라우터는 패킷이 서버 네트워크 게이트웨이에 도달하는 가장 좋은 경로를 결정합니다. 거기에서 링크 계층이 작용합니다.

 

텍스트가 인터넷에 전달되는 과정에 대한 단계별 설명

  1. 초기 전송 :
  2. 지역 네트워크 :
  3. 로컬 라우터 처리 :
  4. 네트워크 간 라우팅 :
  5. 최종 네트워크
  6. 서버 접수 :
  7. 서버 처리 :
⁉️
인터넷을 통해 패킷을 보내는 프로세스(네트워크 계층)는 본질적으로 인터넷을 통한 모든 통신에 사용됩니다. 따라서 이전의 모든 단계(도메인 이름 확인, TCP 핸드셰이크 등)에 사용되었지만 한 번에 설명할 수 있는 내용은 제한적입니다.

6. 서버 응답

서버는 HTTP 요청을 수신하여 처리합니다. 요청을 처리한 후, 서버는 HTTP 응답을 클라이언트로 다시 보냅니다. 응답에는 다음이 포함됩니다.

  • 프로토콜 (사용되는 HTTP 버전)
  • 상태 정보 (200, 404 등과 같은 HTML 상태 코드)
  • 응답 헤더 (요청 헤더와 유사하지만 응답)
  • 요청된 콘텐츠/본문 (요청 페이지의 HTML이나 JSON 데이터와 같은 실제 콘텐츠)
복사 
HTTP/1.1 200 OK
Date: Sat, 26 May 2023 10:00:00 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Type: text/html
Content-Length: 3456

<!DOCTYPE html>
<html>
<head>
    <title>Example Page</title>
</head>
<body>
    <h1>Hello, world!</h1>
</body>
</html>

 

요청을 디버깅할 때 이와 비슷한 것을 본 적이 있을 수 있습니다.

 

http 서버 응답 분석 화면

 

 

7. 콘텐츠 렌더링 :

클라이언트는 HTTP 응답을 수신하여 처리합니다. 브라우저는 HTML을 해석하여 화면에 콘텐츠를 렌더링합니다. 응답에 추가 리소스(예: 이미지, CSS, JavaScript)가 포함된 경우 브라우저는 동일한 프로세스에 따라 이러한 리소스를 가져오기 위해 추가 HTTP 요청을 합니다.

 

이제 기본적인 HTTP 요청을 마쳤으니, 문제는 하나뿐입니다. 전혀 안전하지 않습니다. 연결을 수신하는 사람은 누구나 주고받는 데이터의 100%를 볼 수 있습니다. 게다가 누군가가 서버인 척해서 클라이언트가 속아서 귀중한 정보를 보낼 수도 있습니다. 바로 여기서 보안 계층이 작용합니다.

 

리틀 레이어 리뷰

여기서 보안 계층을 소개하면서 계층과 그 목적에 대해 간략히 검토해보겠습니다.

  • 애플리케이션 계층 : 애플리케이션이 사용자 데이터를 생성하고 통신하는 곳입니다. 이것은 여러분이 가장 많이 상호 작용한 것입니다. 신뢰할 수 있거나 신뢰할 수 없는 데이터 전송을 위해 전송 계층 서비스를 사용합니다. 프로토콜에는 HTTP, FTP, SSH, SMTP가 있습니다. 포트를 사용하여 프로세스/서비스를 처리합니다.
  • 보안 계층 : 암호화, 인증 및 데이터 무결성을 제공하여 안전한 통신을 보장합니다. 일반적인 프로토콜에는 TLS(전송 계층 보안)와 그 전신인 SSL(보안 소켓 계층)이 있습니다. 이 계층은 전송 중인 데이터를 보호하고 통신 당사자의 신원을 확인합니다.
  • 전송 계층 : 호스트 간 통신을 관리하고 애플리케이션 데이터에 대한 채널을 제공합니다. 다음이 포함됩니다.
  • 네트워크 계층 : 다양한 중간 라우터를 통해 패킷을 라우팅하여 네트워크 경계를 가로질러 패킷을 교환하는 것을 담당합니다. 기본 프로토콜: 인터넷 프로토콜(IP).
  • 링크 계층 : 라우터 없이 로컬 네트워크 통신을 관리합니다. 이웃 호스트에 데이터그램을 전송하기 위한 로컬 네트워크 토폴로지와 인터페이스를 정의합니다.

특히 보안 계층 에 주의하세요. 이 계층은 HTTP 요청(방금 다룬 내용)과 HTTPS 요청( 현재 인터넷의 약 86%를 차지하고 있으며 계속 증가하고 있음) 의 결정적인 차이점입니다.

 

HTTPS = HTTP + 암호화

HTTPS는 암호화 및 검증이 포함된 HTTP입니다. 인터넷을 통한 HTTP 통신을 보호하는 방법은 여러 가지가 있지만 현재 모든 사람이 사용하는 구현은 전송 계층 보안(TLS) 입니다 .

 

TLS는 클라이언트와 서버가 서로의 신원을 확인하고 모든 페이로드가 양측이 해독할 수 있는 방식으로 암호화되도록 하는 방법입니다. 특히 TLS 핸드셰이크 프로세스는 클라이언트와 서버가 암호화 및 검증 키를 교환하는 방법을 결정합니다. 키가 교환되면 클라이언트와 서버는 평소처럼 HTTP를 사용하여 통신하고 키를 사용하여 메시지를 암호화하고 검증합니다.

 

HTTPS의 흐름은 이전에 다루었던 HTTP 요청과 정확히 동일하지만, 애플리케이션 계층과 전송 계층 사이에 보안 계층이 추가되었습니다(일반적으로 TLS 핸드셰이크에는 TCP가 사용됩니다).

 

HTTP + 암호화 절차 그림

TLS 핸드셰이크

TLS 핸드셰이크는 클라이언트와 서버가 통신의 몇 가지 다른 측면에 대해 합의하기 위한 것입니다. 구체적으로는 메시지를 검증, 압축 및 암호화하는 데 사용될 알고리즘 모음입니다.

요소
설명/목적
일반적인 구현
현재 주로 사용됨
압축 알고리즘
클라이언트와 서버가 전선을 통해 데이터를 압축하는 방법
Gzip, 브로틀리
브로틀리
키 교환 알고리즘
공개 채널을 통해 암호화 키를 안전하게 교환하세요
ECDHE-RSA, ECDHE-ECDSA
ECDHE(완벽한 전방 비밀성 제공)
인증 알고리즘
악수 시 당사자의 신원을 인증합니다.
RSA, ECDSA
RSA(널리 사용됨), ECDSA(인기가 높아지고 있음)
대칭 암호화 알고리즘
클라이언트와 서버 간에 전송되는 데이터를 암호화합니다.
AES-128-GCM, AES-256-GCM
AES-GCM(강력한 보안 및 효율성 제공)
MAC 알고리즘
메시지의 무결성과 진위성을 보장합니다.
HMAC-SHA256, HMAC-SHA384
HMAC-SHA256(공통), 최신 암호 제품군의 GCM 모드
🔒
이 알고리즘 모음은 암호 모음이라고 합니다 . 구체적으로 압축 알고리즘을 제외한 모든 알고리즘이 암호 모음으로 간주되지만, 간결하게 하기 위해 앞으로는 전체 알고리즘 모음을 암호 모음이라고 부르겠습니다.

 

이 모든 알고리즘에 동의하고, 랜덤 시드와 개인 키가 포함된 서버의 SSL 인증서를 교환함으로써 클라이언트와 서버는 주고받는 메시지를 암호화하고 검증하는 데 사용될 대칭 키를 생성할 수 있습니다. 암호화 제품군에 동의하고 필요한 정보(시드와 SSL 인증서)를 배포하는 이 프로세스를 TLS 핸드셰이크라고 합니다.

 

참고: 모든 통신은 TCP를 통해 이루어지며, 파란색 단계는.CP 핸드셰이크를 나타내고 노란색 단계는.LS 핸드셰이크를 나타냅니다.

 

TLS 핸드셰이크

  1. 고객 안녕하세요
  2. 서버 안녕하세요
  3. 인증서 검증
  4. 프리마스터 시크릿 제너레이션
  5. 복호화
  6. 세션 키 생성
  7. 클라이언트 준비 완료
  8. 서버 준비 완료
  9. 보안 HTTP 통신

붐. TLS 핸드셰이크는 한 가지 더 있는데, 그것은….

 

여기서 당신이 배운 모든 것은 거짓말입니다.

방금 설명한 프로세스는 TLS 원래 버전을 위한 것인데, 이는 TLS 1.3의 최신 버전에 비해 오래된 버전입니다.

 

TLS 1.3의 핸드셰이크의 차이점은 무엇입니까?

방금 살펴본 프로세스는 조금 오래되었지만, 보안 서버 <> 클라이언트 통신에 대해 합의해야 할 필수 개념을 소개하고 있기 때문에 시작하기에 좋은 곳입니다.

 

현재 버전의 TLS(>1.3)는 보안상의 이유로 RSA(및 기타 다양한 암호화 제품군)를 지원하지 않습니다. 최신 버전은 더 고집이 세고, 상당히 적은 옵션을 허용하여 더 간단하고, 더 안전하고, 더 빠릅니다. 그러나 구성 요소와 개념은 모두 매우 동일합니다. 여전히 TCP를 통해 교환되는 패킷의 데이터를 보호하기 위한 대칭 암호화 키를 생성하기 위해 압축 방법, 서버 인증 및 키 교환에 동의하는 TLS 핸드셰이크 프로세스가 있습니다.

 

TLS 1.3은 RSA를 지원하지 않으며, 공격에 취약한 다른 암호 제품군 및 매개변수도 지원하지 않습니다. 또한 TLS 핸드셰이크를 단축하여 TLS 1.3 핸드셰이크를 더 빠르고 안전하게 만듭니다.

 

TLS 1.3 핸드셰이크의 기본 단계는 다음과 같습니다.

  • 클라이언트 헬로: 클라이언트는 프로토콜 버전, 클라이언트 랜덤, 암호 제품군 목록이 포함된 클라이언트 헬로 메시지를 보냅니다. TLS 1.3에서 안전하지 않은 암호 제품군에 대한 지원이 제거되었기 때문에 가능한 암호 제품군의 수가 크게 줄었습니다. 클라이언트 헬로는 또한 프리마스터 비밀을 계산하는 데 사용될 매개변수를 포함합니다. 기본적으로 클라이언트는 서버의 선호하는 키 교환 방법을 알고 있다고 가정합니다(암호 제품군 목록이 간소화되었기 때문에 아마도 알고 있을 것입니다). 이렇게 하면 핸드셰이크의 전체 길이가 줄어듭니다. 이는 TLS 1.3 핸드셰이크와 TLS 1.0, 1.1, 1.2 핸드셰이크의 중요한 차이점 중 하나입니다.
  • 서버가 마스터 시크릿을 생성합니다. 이 시점에서 서버는 클라이언트 랜덤과 클라이언트의 매개변수 및 암호 모음을 수신했습니다. 서버는 이미 서버 랜덤을 가지고 있는데, 스스로 생성할 수 있기 때문입니다. 따라서 서버는 마스터 시크릿을 생성할 수 있습니다.
  • 서버 hello 및 "Finished": 서버 hello에는 서버의 인증서, 디지털 서명, 서버 랜덤 및 선택한 암호 모음이 포함됩니다. 마스터 비밀이 이미 있으므로 "Finished" 메시지도 보냅니다.
  • 마지막 단계 및 클라이언트 "완료": 클라이언트는 서명과 인증서를 검증하고, 마스터 비밀을 생성하고, "완료" 메시지를 보냅니다.
  • 안전한 대칭 암호화가 달성되었습니다.

 

이제 가세요. 나가서 기술 면접에서 최고가 되세요.

 

*참고한 원본 글: https://devonperoutky.super.site/blog-posts/mediocre-engineers-guide-to-https

 

 

브라우저의 숨겨진 프로필 기능으로 쾌적한 인터넷 사용하기 (크롬, 파이어폭스, 에지)

이 단계에서 브라우저에 대해 잘 알고 있다고 생각할 수 있지만 많은 관심을 받지 못하고 간과했을 수 있는 매우 강력한 기능이 하나 있습니다. 바로 사용자 프로필입니다. Chrome, Edge 또는 Firefox

icandothat.tistory.com

 

 

PC 설정으로 광대역 인터넷 속도를 확 높이는 방법 (윈도우 등)

21세기에는 개개인이 항상 서두르고 있음을 목격할 수 있다. 모든 개인의 삶에는 완수해야 할 많은 과제가 있고 그것이 바로 우리가 빠른 속도를 선호하는 이유입니다. 우리는 인터넷 속도의 경

icandothat.tistory.com

 

 

인터넷 McAfee(맥아피) 사기 8가지 유형과 발생시 돈을 돌려받는 방법

McAfee와 같은 컴퓨터 보안 소프트웨어 회사에서 사기를 당할 수 있습니까? 공식 McAfee 회사에서 사기를 당할 가능성은 거의 없습니다. 그러나 잘 알려진 McAfee 이름을 이용하려는 많은 사기꾼이 있

lifegoodtip.tistory.com

반응형
그리드형
저작자표시 비영리 변경금지

'개발일기 > 설계와디자인' 카테고리의 다른 글

최고의 무료 CAD(캐드) 소프트웨어/프로그램 10개 - 업무용, 스터디용  (0) 2023.02.25
monolithic time(모노리틱 타임)이란? monotonic time(모노토닉 타임)과의 차이점  (0) 2022.07.03
일론 머스크에게서 배우는 설계와 개발의 원칙들  (0) 2022.02.27

관련글

댓글

티스토리툴바