평범한 엔지니어를 위한 HTTPS 가이드

(devonperoutky.super.site)

6P by GN⁺ 2024-05-27 | ★ favorite | 댓글 1개

인터넷 통신은 패킷을 여러 계층이 나눠 처리하는 구조이며, 계층화된 프로토콜 덕분에 개발자는 전송·라우팅·보안 세부 구현을 직접 다루지 않아도 됨
HTTP 요청은 브라우저의 메시지 생성에서 시작해 DNS 조회, TCP 3-way handshake, 라우터 경유, 서버 응답으로 이어지는 단계적 흐름을 따름
기본 HTTP는 헤더와 본문이 평문으로 오가므로 도청과 서버 사칭에 취약하며, 이 한계를 메우기 위해 보안 계층이 추가됨
HTTPS는 HTTP에 TLS 암호화와 검증을 더한 형태이며, TLS handshake는 버전·cipher suite·인증서·키 교환 정보를 맞춰 대칭 세션 키를 만드는 과정임
TLS 1.3은 RSA와 취약한 cipher suite·파라미터를 제외하고 선택지를 줄여, 이전 방식보다 더 단순하고 빠르며 안전한 handshake를 구성함

인터넷 통신을 보는 계층 모델

인터넷은 상호 연결된 컴퓨터 네트워크들의 네트워크이며, “Internet”은 문자 그대로 “네트워크 사이”를 뜻함
패킷 교환 방식의 메시 네트워크로 동작하며, 패킷 전달 여부나 도착 시간은 보장되지 않는 best-effort delivery 구조임
재시도, 순서 보장, 중복 제거, 보안 같은 처리를 여러 추상화 계층이 뒤에서 맡기 때문에 인터넷이 매끄럽게 동작하는 것처럼 보임
각 계층은 특정 기능을 제공하고, 서로 다른 프로토콜이 그 기능을 구현할 수 있음
- 이런 모듈화 덕분에 한 계층의 프로토콜을 바꿔도 다른 계층의 프로토콜에 영향을 주지 않을 수 있음

네트워크 계층별 역할

Application layer는 애플리케이션별 로직을 처리하며, 통신 단위는 메시지이고 HTTP가 대표 예시임
Security layer는 암호화와 인증을 제공하며, 통신 단위는 record이고 TLS가 예시임
Transport layer는 신뢰성 있는 데이터 전송을 담당하며, TCP segment 또는 UDP datagram을 사용하고 포트 번호로 식별함
Network layer는 인터넷을 가로질러 패킷을 라우팅하며, IP 주소를 식별자로 사용함
Link layer는 물리 매체와 가까운 통신을 관리하며, frame을 사용하고 MAC 주소로 식별함
Physical layer는 비트를 장치 간에 물리적으로 전송하며, 광섬유나 Ethernet cable이 예시임

HTTP 요청의 흐름

1. 클라이언트가 요청 생성
- 과정은 Application layer에서 시작하며, 클라이언트는 보통 웹 브라우저임
- HTTP는 텍스트 기반 프로토콜이라 데이터가 평문으로 전송됨
- HTTP 요청의 첫 줄에는 보통 HTTP method, 요청 리소스, 프로토콜 버전이 들어감
  - HTTP method: GET, POST 등
  - 요청 리소스: 예를 들어 /index.html
  - 프로토콜 버전
- 나머지 HTTP 메시지에는 key: value 형식의 헤더와 선택적 본문이 포함됨
```
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을 93.184.216.34 같은 IP 주소로 변환함
- 클라이언트는 DNS 서버에 질의해 도메인 이름을 IP 주소로 해석함
- 이 과정은 여러 resolver를 거쳐 최종적으로 authoritative server에 도달함
- Stub resolver는 클라이언트 머신에 있으며, 요청을 적절한 recursive resolver로 전달함
- Recursive resolver는 stub resolver의 요청을 받고 authoritative server에 질의하며, 결과를 캐시하는 경우가 많음
- ISP가 보통 recursive resolver를 제공하고, Google DNS 8.8.8.8 같은 공개 resolver도 사용할 수 있음
- Authoritative server는 A, MX, CNAME 같은 실제 DNS record를 가지고 있으며, 도메인 이름 데이터의 최종 출처임
3. TCP handshake
- 서버 IP 주소를 얻으면 클라이언트는 Transport layer에서 HTTP 전송을 준비함
- 전송 계층의 주요 프로토콜은 TCP와 UDP임
- TCP는 연결 지향 프로토콜이며, 애플리케이션 간 데이터 전달의 신뢰성, 순서, 오류 검사를 보장함
- UDP는 비연결 프로토콜이며, 전달·순서·오류 검사를 보장하지 않는 대신 빠르고 오버헤드가 낮음
- 2024년 기준 TCP는 인터넷 데이터 전송 관리의 주요 프로토콜이며, UDP는 스트리밍이나 영상 통화처럼 낮은 지연 시간이 중요하고 일부 패킷 손실을 허용할 수 있는 실시간 애플리케이션에 주로 쓰임
- HTTP의 표준 포트인 80번 포트로 TCP 연결을 시작하며, 3단계 handshake를 거침
  - SYN: 클라이언트가 연결 요청을 위해 SYN 패킷을 보냄
  - SYN-ACK: 서버가 SYN-ACK 패킷으로 요청을 승인함
  - ACK: 클라이언트가 ACK 패킷을 보내 신뢰성 있는 연결이 성립됨
4. HTTP 요청 전송
- TCP 연결이 준비되면 클라이언트가 실제 HTTP 요청을 보냄
- HTTP는 텍스트 기반 프로토콜이므로 요청 헤더와 본문이 있으면 본문까지 평문으로 전송됨

패킷이 서버까지 가는 방식

클라이언트가 요청을 보내면 데이터 패킷은 서버로 직접 이동하지 않고, 여러 네트워크 장비와 라우터를 거쳐 서버 네트워크 게이트웨이에 도달할 경로를 찾음
이후 Link layer가 로컬 구간의 전송을 담당함
텍스트가 인터넷을 건너가는 단계
- 클라이언트 장치는 HTTP 요청 데이터를 TCP segment로 캡슐화하고, 다시 IP packet으로 감쌈
- 유선 연결이라면 Ethernet frame 같은 Link layer frame으로 한 번 더 캡슐화됨
- frame은 로컬 네트워크를 통해 클라이언트의 라우터로 전송됨
- 로컬 라우터는 frame을 받고 Link layer header를 제거한 뒤 IP packet을 처리함
- 라우터는 목적지 IP 주소를 보고 다음 hop을 결정함
- 패킷은 하나 이상의 중간 라우터를 거쳐 다음 네트워크로 전달되고, 각 라우터는 다음 hop을 정해 전달하는 과정을 반복함
- 패킷은 결국 목적지 서버와 같은 네트워크에 있는 라우터에 도달함
- 이 라우터는 최종 라우팅 결정을 내리고 서버에 해당하는 로컬 장치로 패킷을 보냄
- 서버의 라우터는 로컬 네트워크 segment를 통해 패킷을 서버로 전달함
- Link layer는 frame이 서버의 네트워크 인터페이스에 올바르게 전달되도록 함
- 서버는 frame을 받고 IP packet을 추출한 뒤, 캡슐화된 TCP segment를 처리해 원래 HTTP 요청을 재구성함
- 인터넷을 가로질러 패킷을 보내는 Network layer 과정은 도메인 이름 해석이나 TCP handshake 같은 이전 단계에도 사용됨

서버 응답과 브라우저 렌더링

서버는 HTTP 요청을 처리한 뒤 클라이언트로 HTTP 응답을 보냄
응답에는 사용 중인 HTTP 버전, 200·404 같은 상태 코드, 응답 헤더, 요청한 페이지의 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 응답을 받고 처리함
브라우저는 HTML을 해석해 화면에 콘텐츠를 렌더링함
응답에 이미지, CSS, JavaScript 같은 추가 리소스가 있으면 브라우저는 같은 과정을 따라 추가 HTTP 요청을 보냄

HTTP의 보안 문제와 HTTPS

기본 HTTP에는 보안이 전혀 없음
연결을 듣는 사람은 주고받는 데이터 100%를 볼 수 있음
누군가 서버인 척하면 클라이언트가 중요한 정보를 잘못된 대상에게 보낼 수 있음
HTTPS는 HTTP에 암호화와 검증을 더한 형태임
HTTP 통신을 안전하게 만드는 방식은 여러 가지가 있지만, 현재 일반적으로 쓰이는 구현은 TLS임
TLS는 클라이언트와 서버가 서로의 신원을 검증하고, 양쪽이 복호화할 수 있는 방식으로 payload를 암호화하도록 함
HTTPS 요청의 흐름은 앞서 본 HTTP 요청 흐름과 같지만, Application layer와 Transport layer 사이에 Security layer가 추가됨
- TLS handshake에는 보통 TCP가 사용됨

TLS handshake가 합의하는 것

TLS handshake는 클라이언트와 서버가 통신에 사용할 여러 요소에 합의하는 과정임
합의 대상에는 메시지 검증, 압축, 암호화에 사용할 알고리듬 모음이 포함됨
이 알고리듬 모음은 cipher suite라고 불림
- 엄밀히는 compression algorithm을 제외한 나머지가 cipher suite지만, 글에서는 전체 모음을 cipher suite로 부름
예시 구성 요소는 다음과 같음
- Compression algorithm: wire 위에서 데이터를 압축하는 방식이며, Gzip과 Brotli가 예시이고 현재 주로 Brotli가 사용됨
- Key exchange algorithm: 공개 채널에서 암호화 키를 안전하게 교환하는 방식이며, ECDHE-RSA와 ECDHE-ECDSA가 예시이고 현재 주로 ECDHE가 사용됨
- Authentication algorithm: handshake 중 당사자의 신원을 인증하는 방식이며, RSA와 ECDSA가 예시이고 RSA가 널리 쓰이며 ECDSA도 인기를 얻고 있음
- Symmetric encryption algorithm: 클라이언트와 서버 사이의 데이터를 암호화하는 방식이며, AES-128-GCM과 AES-256-GCM이 예시이고 AES-GCM이 강한 보안과 효율을 제공함
- MAC algorithm: 메시지의 무결성과 진위를 보장하는 방식이며, HMAC-SHA256과 HMAC-SHA384가 예시이고 HMAC-SHA256과 최신 cipher suite의 GCM mode가 사용됨
클라이언트와 서버는 cipher suite에 합의하고, 난수 seed와 SSL certificate 정보를 교환해 메시지 암호화와 검증에 사용할 대칭 키를 만들 수 있음
TLS handshake 자료 출처는 Cloudflare임

기존 TLS handshake 단계

Client Hello
- 클라이언트가 지원하는 cipher suite, 지원 TLS version, Client Random이라는 난수를 포함한 TCP 메시지를 서버에 보냄
Server Hello
- 서버가 선택한 TLS version, 선택한 cipher suite 알고리듬, Server Random을 포함한 TCP 메시지로 응답함
Certificate Verification
- 클라이언트가 Certificate Authority를 통해 서버의 SSL certificate를 검증하고 서버의 public key를 가져옴
Premaster Secret Generation
- 클라이언트가 premaster secret을 만들고 서버의 public key로 암호화해 서버에 보냄
Decryption
- 서버가 private key를 사용해 premaster secret을 복호화함
Session Key Creation
- 클라이언트와 서버가 Client Random, Server Random, premaster secret을 사용해 session key를 만듦
Client Ready
- 클라이언트가 session key로 암호화한 finished 메시지를 보냄
Server Ready
- 서버가 session key로 암호화한 finished 메시지를 보냄
Secure HTTP Communication
- 이후 session key를 사용한 안전한 대칭 암호화로 양쪽이 통신함

TLS 1.3에서 달라진 점

앞서 설명한 TLS handshake는 원래 TLS 버전에 대한 과정이며, 최신 TLS 1.3 기준으로는 오래된 방식임
TLS 1.3 이상은 보안상 이유로 RSA와 여러 cipher suite를 지원하지 않음
최신 버전은 선택지를 크게 줄여 더 단순하고, 더 안전하며, 더 빠름
TLS 1.3에서도 핵심 개념은 유지됨
- handshake를 통해 압축 방식, 서버 인증, 키 교환에 합의함
- TCP를 통해 교환되는 패킷 데이터를 보호하기 위해 대칭 암호화 키를 생성함
TLS 1.3은 공격에 취약한 cipher suite와 파라미터를 지원하지 않으며, handshake를 줄여 더 빠르고 안전한 handshake를 만듦
TLS 1.3 handshake의 기본 단계
- Client hello: 클라이언트가 프로토콜 버전, Client Random, cipher suite 목록을 보냄
  - TLS 1.3에서는 안전하지 않은 cipher suite 지원이 제거되어 가능한 cipher suite 수가 크게 줄어듦
  - Client hello에는 premaster secret 계산에 사용할 파라미터도 포함됨
  - 클라이언트는 서버가 선호하는 key exchange method를 안다고 가정하며, 줄어든 cipher suite 목록 때문에 그럴 가능성이 높음
  - 이 구조가 TLS 1.0, 1.1, 1.2 handshake보다 전체 길이를 줄임
- Server generates master secret: 서버는 Client Random, 클라이언트 파라미터, cipher suite를 받은 상태이며 Server Random을 직접 생성할 수 있어 master secret을 만들 수 있음
- Server hello and Finished: Server hello에는 서버 certificate, digital signature, Server Random, 선택된 cipher suite가 포함됨
  - 서버는 이미 master secret을 가지고 있으므로 Finished 메시지도 함께 보냄
- Final steps and client Finished: 클라이언트는 signature와 certificate를 검증하고 master secret을 생성한 뒤 Finished 메시지를 보냄
- Secure symmetric encryption achieved: 이후 안전한 대칭 암호화가 성립됨

GN⁺ 2024-05-27 [-]

Hacker News 의견들

비전문가로서 궁금한데, 특정 웹사이트나 인터넷 전체에 접근이 안 될 때 어느 구간에서 장애가 났는지 왜 이렇게 알기 어려운지 모르겠음
내 로컬 머신의 네트워크 설정 오류인지, 라우터까지의 Wi-Fi 연결 문제인지, 라우터와 ISP 사이 케이블 문제인지, ISP의 대규모 장애인지, 접속하려는 웹사이트 장애인지가 자주 불분명함
요청이 비결정적 경로로 라우팅되기 때문이라는 막연한 설명을 들었지만 설득력은 약함. 경로 중 어떤 링크가 끊기면 마지막으로 정상인 링크가 “네 메시지는 여기까지 왔지만 다음 단계로 보내려다 실패했다”라고 뒤로 알려주면 안 되는지 궁금함
- 동작 원리를 알면 정확히 무엇이 실패했는지 알아낼 수는 있지만, 사용자에게 유용한 설명을 주는 진단 도구를 만들기는 거의 불가능함
  설정은 제각각이고, 어떤 구성이 의도된 것인지 알 수 없으며, 흔한 원인에 근거해 가정했다가 완전히 틀린 답을 제시하면 위험함
  예를 들어 DNS 서버도 응답하지 않고 대상 호스트도 응답하지 않으면 라우터 설정 오류나 ISP 장애라고 말할 수 있겠지만, 실제 원인은 VPN 클라이언트가 로컬 라우팅 테이블과 DNS 서버를 바꾼 뒤 종료 시 되돌리지 못한 것일 수 있음. 임시 변경인지 영구 설정인지 진단기가 어떻게 알 수 있겠냐는 문제임
- ICMP가 네트워크로 들어오는 것이 허용되어 있다면, 패킷을 더 전달하지 못한 호스트로부터 Destination Unreachable 응답을 받을 가능성이 큼
  애플리케이션은 소켓을 그렇게 설정하지 않으면 ICMP 메시지를 보지 못함. 이런 것은 “일시적” 오류로 취급되며, Linux에서는 IP_RECVERR 소켓 옵션으로 설정함
  7계층에서 작업할 때는 이 계층의 오류를 수집해도 가치가 크지 않음. 위로 드러나는 Destination Unreachable 오류는 이미 갖추게 될 실패 처리 로직에 맞춰질 것이고, 이 경우 다른 계층들이 도달 불가능한 목적지에 대해 재시도를 하므로 아마 시간 초과로 보일 것임
  TCP 계층이 ICMP 오류를 어떻게 처리하는지에는 이 RFC들이 도움이 됨: https://www.rfc-editor.org/rfc/rfc1122#page-103
  4.2.3.9에는 Unreachable 메시지가 soft error 조건이므로 TCP가 연결을 중단해서는 안 되며, 정보를 애플리케이션에 제공해야 한다고 나옴. TCP는 ERROR_REPORT 루틴으로 애플리케이션 계층에 올려보내거나, 메시지를 기록했다가 TCP 연결이 시간 초과될 때만 애플리케이션에 보고할 수 있음
  TCP 공격 벡터로서 ICMP를 연구하기 위해 스택들이 어떻게 상호작용하는지 더 자세히 다루는 문서도 있음: https://www.rfc-editor.org/rfc/rfc5927
- 브라우저는 당시 하던 작업에 가장 가까운 오류를 보고함. 호스트를 찾지 못했다면, DNS 서버에는 도달했고 그 서버가 이름에 대한 주소가 없다고 응답했다는 뜻에 가까움
  DNS 서버 자체에 도달할 수 없다면 사용자와 그 서버 사이의 어떤 네트워크 오류임. 보통은 단계를 직접 수행해 진단함. DNS 서버 주소로 ping이 되는지, 그 DNS 서버로 해당 호스트를 해석할 수 있는지, 다른 DNS 서버에서는 어떤지 확인함. 회사 정책 때문에 특정 이름이 제외될 수도 있음
  더 파고들고 싶다면 ping, traceroute, dig 같은 명령줄 도구가 유용함
- 이런 문제의 상당 부분은 문제 해결 시 목적지까지 MTR을 실행해 각 홉의 세부 정보를 보는 방식으로 해결해왔음
  MTR은 실시간으로 계속 도는 ping + traceroute 같고, 각 홉이 따로 표시됨
  Xfinity 네트워크에서 노드가 죽은 것을 처음 알아챌 때도, 같은 MTR에서 적어도 내 네트워크부터 모뎀까지는 정상임을 볼 수 있어 일관적이었음. ISP 너머의 어떤 홉에서 지연 시간이 수백 ms 늘어나는 것도 MTR만큼 잘 보여주는 도구를 많이 보지 못함
  모든 문제를 해결하지는 못하지만, 홉별로 나눠 지연 시간을 제공하므로 확인해볼 만함
- 무엇으로 확인하려는지가 중요함. 웹브라우저가 URL에 접근하지 못해도 정확한 원인을 말해주지 않는 것은, 진단이 틀릴 가능성이 있고 대부분의 사용자가 혼란스러워하기 때문임
  “문제는 여기다”라고 말하려면 운영체제, 하드웨어, 네트워크가 어떻게 구성됐는지에 대한 가정이 필요함
  웹사이트에 접속할 때 먼저 DNS에서 웹서버의 IP 주소를 받아야 하는데, 브라우저가 DNS IP를 어디서 얻는지가 이미 복잡함. 브라우저, 운영체제, 라우터, 모뎀에 설정할 수도 있고, 설정하지 않으면 라우터가 연결한 DHCP 서버에서 받음. 그것이 ISP의 DHCP 서버일 수도, 조직 내부의 다른 라우터일 수도 있음
  DNS가 이상해 보이면 IP가 틀렸다는 건 알기 쉽지만 그 IP가 어디서 왔는지 말하기는 어려움. SSL도 서버 인증서가 잘못됐을 수도 있고 내 컴퓨터의 인증서가 잘못됐을 수도 있음
관련 있을 수 있는데, TLSv1.2와 TLSv1.3에 대해 바이트 단위로 자세히 따라가는 대화형 예제도 있음
TLS를 더 배우고 싶다면 정말 좋아하는 자료라 강력히 추천함
[0]: https://tls12.xargs.org/
[1]: https://tls13.xargs.org/
이런 관점으로 쓴 글 예시가 더 있는지 궁금함. 숙련도와 상관없이 “그럭저럭인 엔지니어에게 설명하듯” 풀어쓴 글을 좋아함
완전히 명확하지 않았던 조각을 새로 배우거나, 다른 사람에게 설명할 때 쓸 예시를 더 얻을 수 있어서 대체로 매우 유용함
- 이 글은 대체로 Cloudflare 블로그/글 3~4개를 요약한 느낌임. 이런 내용이 더 필요하면 CF 학습 센터를 보면 됨: https://www.cloudflare.com/learning/
  예시:
  https://www.cloudflare.com/learning/dns/what-is-dns/
  https://www.cloudflare.com/learning/ssl/transport-layer-secu...
  https://www.cloudflare.com/learning/performance/what-is-http...
“클라이언트가 premaster secret을 생성해 서버의 공개키로 암호화한 뒤 서버에 보낸다”는 설명은 이미 오래전부터 사실이 아님
- 아래에 “여기서 배운 모든 것은 거짓말이다”라고 되어 있음
  방금 설명한 과정은 현대적인 TLS 1.3과 비교하면 낡은 TLS 초기 버전의 과정이라고 덧붙여져 있음
“현재 TLS 버전(>1.3)은 보안상 이유로 RSA와 여러 암호군을 지원하지 않는다”는 말은 키 교환 부분에서는 맞음. RSA는 전방향 안전성(forward secrecy)을 제공하지 않기 때문임
서명에는 RSA가 여전히 쓰이고, 아마 x509 인증서에서 가장 널리 퍼진 종류일 것임
Safari도 얼마 전 RSA 서명에 대해 2048비트 키 요구사항을 올린 것으로 알고 있음
이 글은 실제 HTTPS 설명 글을 AI가 요약한 것처럼 읽힘. 용어가 맥락 없이 등장함
인증서가 무엇인지, 신뢰 사슬이 어떻게 동작하는지 설명하지 않고, 독자가 공개키 암호화를 안다고 가정함. OSI 7계층 중 6개를 설명하면서도 그 용어 자체는 말하지 않고, 표현 계층은 빠져 있음
물론 제목부터 mediocre라고 하긴 함
- 공평하게 말하면 세션 계층도 넣지 않았음
  글쓰기가 강점은 아니라서 비판은 고맙게 받아들임. 내 글이 “나쁘다”에서 “AI인가?”로 간 건 발전임
  설명을 어디서 끊을지 고민했고, 공개키 암호화는 다른 곳에서 더 잘 설명될 수 있는 좋은 경계라고 봤음. OSI 여러 계층도 마찬가지였음
  인증서와 어쩌면 전체 신뢰 사슬은 다뤘어야 했다는 점은 인정함
SHA256(client_hello_random + server_hello_random + curve_info + public_key)의 서명 검증을 보여주는 코드를 찾지 못하겠음
이론은 알지만 구현하려니 뭔가 문제가 생김. 실제로 어떻게 하는지 보여주는 장난감 프로그램 링크가 있으면 좋겠음
“서버의 SSL 인증서에 개인키가 들어 있다”는 식의 표현은 제발 아니길 바람. 그래도 제목이 “Mediocre Engineer”이긴 함
TLS <1.3도 글에서 묘사한 방식으로 동작하지 않는데, 그러면서 1.3의 더 새로운 요소를 섞으려 함. DNS 부분은 재귀 해석기를 설명하지만 클라이언트가 그렇게 하지는 않고, 아마 스텁 해석기와 통신할 것임
“Internet Layer”, brotli가 TLS 압축이나 암호군에서 널리 쓰이는 알고리즘이라는 암시, “현재 TLS 버전(>1.3)은 RSA를 지원하지 않는다” 같은 오류가 계속 나옴
이런 블로그스팸 때문에 가끔은 downvote가 있었으면 함. 광고가 flag할 만큼 거슬리지는 않지만 수준은 낮음. 차라리 덜 mediocre한 글을 써서 HN 첫 페이지에 올려야 할지도 모르겠음. 연봉 $300K를 벌었다면 시간이 더 있었을 텐데
글의 내용은 전반적으로 조금 낡았음. 요즘 웹 요청의 30%는 HTTP/3이고 CORS도 있는데, 게시일이 없음
- 요청의 30%가 CORS라는 건가? 개발하는 종류에 크게 달릴 것임
  나는 보통 기업 네트워크 내부에 배포되는 SaaS 시스템을 개발하는데, CORS 요청은 거의 0%에 가까움. HTTP/3도 마찬가지임

답변달기

평범한 엔지니어를 위한 HTTPS 가이드

인터넷 통신을 보는 계층 모델

네트워크 계층별 역할

HTTP 요청의 흐름

1. 클라이언트가 요청 생성

2. DNS 조회

3. TCP handshake

4. HTTP 요청 전송

패킷이 서버까지 가는 방식

텍스트가 인터넷을 건너가는 단계

서버 응답과 브라우저 렌더링

HTTP의 보안 문제와 HTTPS

TLS handshake가 합의하는 것

기존 TLS handshake 단계

Client Hello

Server Hello

Certificate Verification

Premaster Secret Generation

Decryption

Session Key Creation

Client Ready

Server Ready

Secure HTTP Communication

TLS 1.3에서 달라진 점

TLS 1.3 handshake의 기본 단계

함께 보면 좋은 글 β

댓글과 토론

Hacker News 의견들