0. 자물쇠 하나의 무게
브라우저 주소창 왼쪽의 작은 자물쇠. 사용자는 보통 2초도 보지 않고 지나간다. 그런데 그 자물쇠 뒤에는:
- 1994년 Netscape 의 SSL 1.0 프로토타입.
- 1999년 IETF 의 TLS 1.0 표준화.
- 2014년 Heartbleed 라는 인터넷 역사상 최악의 버그.
- 2018년 TLS 1.3 의 대개편.
- 2024년 Chrome 이 양자내성 암호 (Kyber) 를 실제 배포.
브라우저가 매 HTTPS 요청마다 하는 일 — "처음 본 서버를 믿을 수 있는가?", "이 통신을 누군가 엿듣고 있지 않은가?", "이 패킷이 변조되지 않았는가?" — 이 세 질문의 답이 TLS 와 PKI 라는 거대한 체계에 있다.
이 글은 그 체계의 안쪽을 파헤친다. 자물쇠를 클릭했을 때 실제로 무슨 일이 벌어지는지, 왜 TLS 1.3 이 TLS 1.2 보다 2배 빠른지, 왜 Let's Encrypt 가 혁명이었는지, 그리고 왜 2024년부터 급하게 양자내성 암호를 배포해야 하는지.
1. TLS 가 해결하는 세 가지 문제
1.1 Confidentiality — 엿듣기 방지
평문 HTTP 는 공유 WiFi 에서 `tcpdump` 한 줄로 읽을 수 있다. 2010년 Firesheep 확장 프로그램이 페이스북 세션 쿠키를 그대로 훔쳐가며 HTTPS 의 필요성을 대중화했다.
해결: **대칭 암호화** (AES, ChaCha20). 클라이언트와 서버가 공유 키로 암호화.
1.2 Integrity — 변조 방지
중간자 (MITM) 가 "100원 송금" 을 "10000원 송금" 으로 바꾸면? 암호화만으로는 못 막는다 (운좋게 복호화 후 유효한 메시지가 되면 그대로 통과).
해결: **MAC (Message Authentication Code)** 또는 **AEAD** (Authenticated Encryption with Associated Data). AES-GCM, ChaCha20-Poly1305.
1.3 Authentication — 상대가 누구인지
"google.com" 에 접속했는데 실제로는 공격자의 서버면? 암호화도 무결성도 의미 없다.
해결: **X.509 인증서** + **PKI (Public Key Infrastructure)**. CA (Certificate Authority) 가 서버의 신원을 보증.
2. 비대칭 암호 — 공유 키 없이 비밀 만들기
2.1 문제: 첫 만남의 딜레마
두 사람이 처음 만나서 암호화 대화를 하려면 공유 키가 필요하다. 하지만 공유 키를 어떻게 주고받는가? 평문으로 보내면 도청됨.
2.2 Diffie-Hellman — 1976년의 기적
W. Diffie, M. Hellman, R. Merkle (2002년 Turing 상) 의 아이디어:
Alice Bob
공개값 g, p 공유 (p 는 큰 소수)
a = random() b = random()
A = g^a mod p B = g^b mod p
A 전송 →
← B 수신
shared = B^a mod p shared = A^b mod p
= g^(ab) mod p = g^(ab) mod p
중간자는 A, B 를 볼 수 있지만 `g^(ab) mod p` 를 계산하려면 a 나 b 를 알아야 함 → **이산 로그 문제** (큰 수에서 불가능).
2.3 RSA — 1977년의 대안
R. Rivest, A. Shamir, L. Adleman:
공개키: (n, e) (n = p*q, p,q 는 비밀 소수)
개인키: d (d*e ≡ 1 mod φ(n))
암호화: c = m^e mod n
복호화: m = c^d mod n
도전: n 에서 p, q 를 구하려면 **큰 수 인수분해** — 고전 컴퓨터로 불가능.
2.4 두 알고리즘의 공존
초기 TLS (1994-2010) 는 주로 RSA:
- 서버가 공개키를 제공.
- 클라이언트가 랜덤 pre-master secret 을 서버 공개키로 암호화해서 보냄.
- 서버만 개인키로 복호화.
문제: **Forward Secrecy 없음**. 서버 개인키가 유출되면 과거 모든 세션 복호화 가능.
2010년 이후 DHE / ECDHE (Diffie-Hellman Ephemeral) 로 전환. 매 세션마다 임시 키 쌍 → 과거 세션 보호.
TLS 1.3 은 **RSA key exchange 를 완전 제거**. 오직 ECDHE 만 허용.
2.5 ECC — 더 적은 비트로 같은 안전
Elliptic Curve Cryptography (1985 제안, 2000년대 보급):
- 타원 곡선 위의 이산 로그 문제 기반.
- **같은 보안 수준에 필요한 키 크기가 훨씬 작음**.
| 대칭 보안 비트 | RSA 키 크기 | ECC 키 크기 |
| --- | --- | --- |
| 80 | 1024 | 160 |
| 128 | 3072 | 256 |
| 256 | 15360 | 512 |
ECC 256 = RSA 3072 수준. 모바일/IoT 에서 특히 유리. 현대 TLS 는 ECC 가 기본.
3. TLS 1.2 핸드셰이크 — 2-RTT 의 춤
Client Server
│ ClientHello │
│ (TLS version, cipher suites, │
│ random, extensions) │
│────────────────────────────────→│
│ │
│ ServerHello │
│ (chosen cipher, random) │
│ Certificate │
│ ServerKeyExchange │
│ (ECDHE params) │
│ ServerHelloDone │
│←────────────────────────────────│
│ │
│ ClientKeyExchange │
│ (ECDHE public) │
│ ChangeCipherSpec │
│ Finished (encrypted) │
│────────────────────────────────→│
│ │
│ ChangeCipherSpec │
│ Finished (encrypted) │
│←────────────────────────────────│
│ │
│ Application Data (encrypted) │
│←──────────────────────────────→│
**핵심**: 데이터 전송 전 2번의 왕복 (2-RTT) 필요. 100ms RTT 면 **200ms 지연**. 웹 페이지 로딩의 체감 병목.
3.1 Cipher Suite 의 해독
`TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` 을 분해:
- `ECDHE`: 키 교환 알고리즘.
- `RSA`: 인증서 타입 (서버 인증).
- `AES_128_GCM`: 대칭 암호 (+ 인증 AEAD).
- `SHA256`: MAC / PRF 에 쓰이는 해시.
이 네 가지 조합의 수가 수백 개. "Null cipher" 나 "export-grade 40-bit" 같은 안전하지 않은 조합이 한동안 남아있었다 (FREAK, Logjam 공격의 근원).
3.2 TLS 1.2 의 약점
- 2-RTT 가 느림.
- 너무 많은 옵션 → 잘못된 설정의 여지 (Diffie-Hellman 512-bit = Logjam).
- MAC-then-Encrypt 모드의 취약점 (Lucky 13, POODLE).
- RSA key exchange = Forward Secrecy 없음.
4. TLS 1.3 — 2018년의 대수술
4.1 설계 철학
> "안전하지 않은 옵션을 **제거** 한다. 설정 실수의 여지를 없앤다."
4.2 1-RTT 핸드셰이크
Client Server
│ ClientHello │
│ (key_share: ECDHE public, │
│ supported_versions: [1.3]) │
│────────────────────────────────→│
│ │
│ ServerHello │
│ (key_share: ECDHE public) │
│ { EncryptedExtensions, │
│ Certificate, │
│ CertificateVerify, │
│ Finished } │
│←────────────────────────────────│
│ │
│ { Finished } │
│ Application Data (encrypted) │
│────────────────────────────────→│
핵심:
- 클라이언트가 ClientHello 에 **바로 ECDHE 공개키** 를 제공 (추측한 curve 로).
- 서버가 ServerHello + 증명서 + Finished 를 한 번에 보냄.
- 클라이언트가 Finished 만 보내고 **바로 데이터** 전송.
1 RTT 완료. TLS 1.2 대비 **2배 빠름**.
4.3 제거된 기능들
- **RSA key exchange**: 사라짐. 오직 ECDHE/DHE.
- **CBC 모드**: 사라짐. 오직 AEAD (GCM, ChaCha20-Poly1305).
- **재협상 (Renegotiation)**: 사라짐.
- **압축**: 사라짐 (CRIME 공격 방지).
- **MD5, SHA-1**: 사라짐.
- **취약 curves** (secp224 등): 사라짐.
허용되는 cipher suite 는 **단 5개**:
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256
잘못 설정할 여지가 구조적으로 없어짐.
4.4 0-RTT Resumption — 거의 즉시 재접속
(이전 세션 있음)
Client Server
│ ClientHello │
│ (key_share, early_data) │
│ [Early Data: GET / HTTP/1.1] │ ← 0-RTT 전송!
│────────────────────────────────→│
│ │
│ ServerHello │
│ { Finished } │
│←────────────────────────────────│
재접속 시 **0 RTT** 로 데이터 시작. 모바일 앱, SPA 에서 극적 체감.
4.5 0-RTT 의 Replay Risk
0-RTT 데이터는 forward secrecy 가 없고 replay 될 수 있다. 공격자가 녹화했다가 재전송 → 서버가 같은 요청 두 번 처리.
→ **멱등한 요청 (GET) 에만** 0-RTT 허용. POST 는 별도 정책. HTTP/3 에서는 서버가 replay 감지 윈도우 유지.
4.6 TLS 1.3 도입 속도
2018 RFC 8446 표준화 → 2020 까지 브라우저 대부분 지원 → 2024 현재 HTTPS 트래픽의 **90%+** 가 TLS 1.3.
5. 인증서 체인 — "처음 본 서버를 믿는 방법"
5.1 체인의 구조
[Root CA: DigiCert Global Root CA] ← 브라우저/OS 에 미리 내장
│ (서명)
▼
[Intermediate CA: DigiCert TLS RSA SHA256 2020 CA1]
│ (서명)
▼
[End-entity: google.com] ← 서버가 제시
브라우저는:
1. 서버로부터 [google.com + Intermediate] 인증서 체인 수신.
2. Intermediate 의 공개키로 google.com 서명 검증.
3. Root CA 의 공개키로 Intermediate 서명 검증.
4. Root CA 는 브라우저가 이미 신뢰하는 것 → 체인 완성.
5.2 인증서 안의 내용 (X.509)
Certificate:
Version: 3
Serial Number: 04:a2:...
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=DigiCert Inc, CN=DigiCert TLS RSA SHA256 2020 CA1
Validity:
Not Before: Jan 1 2025
Not After: Apr 1 2026 ← 수명
Subject: C=US, O=Google LLC, CN=*.google.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public Key: <2048 bits>
X509v3 Extensions:
Subject Alt Name: DNS:*.google.com, DNS:google.com, ...
Key Usage: Digital Signature, Key Encipherment
Extended Key Usage: TLS Web Server Authentication
Authority Information Access: OCSP - http://...
Certificate Policies: 2.23.140.1.2.2 (Organization Validated)
Signature: <Intermediate CA 의 서명>
5.3 CA 의 3가지 레벨
- **DV (Domain Validation)**: 도메인 소유만 확인. 90% 의 HTTPS. Let's Encrypt.
- **OV (Organization Validation)**: 회사 실제 존재 확인. 수동 검증.
- **EV (Extended Validation)**: 회사 법적 존재 심층 확인. 한때 녹색 주소창 표시. 2019년부터 브라우저들이 표시 중단.
5.4 CA 의 신뢰는 어디서 오는가
루트 CA 는 브라우저/OS 에 **하드코딩**:
- Windows/Edge: Microsoft Trust Store.
- macOS/Safari/iOS: Apple Root CA List.
- Firefox: Mozilla 독립 목록.
- Chrome: OS 목록 사용 (단, 2023년부터 자체 Root Store 로 전환 중).
각 벤더가 자체 **CA 심사 프로그램** 운영. 까다로운 감사를 통과해야 추가됨.
5.5 유명한 CA 실패들
- **2011 DigiNotar**: 해킹당해서 google.com 가짜 인증서 발급 → 이란 정부가 Gmail 도청. CA 파산, 모든 트러스트 스토어에서 제거.
- **2015 CNNIC**: 이집트 회사가 중간 CA 받아서 임의 도메인 발급. CNNIC 일부 루트 제거.
- **2017 Symantec**: 수년간 부실 검증 → Google 주도로 점진적 trust 제거. Symantec 은 DigiCert 에 CA 사업부 매각.
"CA 하나를 뚫으면 인터넷 전체" 라는 구조적 약점 → 다음 장의 혁신들.
6. 인증서 투명성 (CT) — 감시의 민주화
6.1 문제의 재확인
CA 가 악성/실수로 잘못된 인증서를 발급해도 피해자가 **모른다**. 자기 도메인의 가짜 인증서가 어딘가 돌아다녀도 검출 못 함.
6.2 CT 의 아이디어
> "모든 새 인증서를 **공개 로그** 에 기록하자. 누구나 감시할 수 있게."
- CA 가 인증서 발급 시 여러 CT 로그 서버에 제출.
- 각 로그 서버가 **Merkle tree** 로 append-only 보증.
- 인증서에 "Signed Certificate Timestamp (SCT)" 첨부 → 브라우저가 로그 기록 여부 검증.
6.3 효과
- 도메인 소유자는 자기 이름으로 발급된 모든 인증서를 crt.sh 같은 사이트에서 확인 가능.
- 이상 발급 → 신속 감지 → CA 조치.
- 2018년부터 Chrome 이 모든 새 인증서에 SCT 요구.
6.4 crt.sh 의 재미있는 효과
자기 회사 도메인을 crt.sh 에 검색하면:
- 개발자가 자기도 모르게 만든 staging 서브도메인 발견.
- 위장된 가짜 도메인 (예: `g00gle.com`) 감지.
- 퇴사한 외주사가 만든 잊힌 서브도메인.
7. Let's Encrypt — HTTPS 의 민주화 (2016)
7.1 2015 이전의 현실
"HTTPS 쓰려면 연 수십 달러 + 매년 수동 갱신 + 설치 난이도" → 전체 웹의 30% 만 HTTPS.
7.2 Let's Encrypt 의 3가지 혁신
1. **무료**: 기부금 + 대기업 후원 (Mozilla, EFF, Akamai, Cisco 등).
2. **자동화**: ACME 프로토콜. `certbot` 명령 한 줄.
3. **짧은 수명** (90일): 자동 갱신 강제 → 탈취된 키의 피해 최소화.
7.3 ACME 프로토콜
1. 계정 생성 (공개키 등록)
2. 주문: "example.com 에 대해 인증서 원함"
3. Challenge:
- HTTP-01: http://example.com/.well-known/acme-challenge/{token} 에 특정 값 업로드
- DNS-01: _acme-challenge.example.com TXT 에 특정 값 설정
4. 서버가 Challenge 검증
5. CSR 제출 → 인증서 발급
7.4 Let's Encrypt 의 수치
- 2024 현재 **약 4억 개** 의 활성 인증서.
- 글로벌 HTTPS 채택률 90%+ 에 결정적 기여.
- Chromium + Let's Encrypt 가 웹 암호화의 기반.
7.5 후발주자들
- **ZeroSSL**: 무료 + GUI 중심.
- **Buypass**: 노르웨이 CA, 역시 무료.
- **AWS Certificate Manager**: AWS 환경 내 무료.
- 주요 CDN (Cloudflare, Fastly) 자체 인증서 발급 통합.
8. 인증서 취소 — 해결되지 않은 문제
8.1 취소가 왜 어려운가
인증서 발급 후 수명이 남았는데 키가 유출되면 → 취소해야 함. 하지만 어떻게 브라우저에 "이 인증서 믿지 마" 를 알리는가?
8.2 CRL (Certificate Revocation List)
CA 가 취소된 인증서 목록을 게시:
- 문제: 목록이 점점 커짐. 매번 다운로드는 비현실.
- 브라우저는 실제로 CRL 을 거의 체크 안 함.
8.3 OCSP (Online Certificate Status Protocol)
매 연결 시 CA 의 OCSP 서버에 "이 인증서 유효?" 쿼리:
- 문제 1: 프라이버시 유출 (CA 가 누가 어디 접속하는지 앎).
- 문제 2: OCSP 서버가 다운되면 fail-open (무시) vs fail-closed (연결 실패) 딜레마. 대부분 fail-open → 사실상 무의미.
- 문제 3: 추가 RTT.
8.4 OCSP Stapling
서버가 주기적으로 OCSP 응답을 받아서 핸드셰이크에 **포함** 시킴:
- 프라이버시 OK.
- 추가 RTT 없음.
- 하지만 광범위하게 배포된 지 오래인데 여전히 많은 서버가 미설정.
8.5 실제 작동 방식 — 푸시 기반
크롬/파폭은 OCSP 대신 자체 "파일 푸시":
- Chrome 의 **CRLSet**: Google 이 선별한 급한 취소만 담은 작은 파일, 주기적 업데이트.
- Firefox 의 **OneCRL**: 비슷한 개념.
- 이렇게라도 해야 그나마 취소가 작동.
8.6 짧은 수명이 최선?
Let's Encrypt 의 90일 주기가 여기서도 타협책. "취소 시스템이 불완전하니, 차라리 자주 갱신하자". Apple 은 2022년 TLS 인증서 최대 수명을 **398일** 로 제한.
9. HSTS, HPKP, CAA — 추가 방어층
9.1 HSTS (HTTP Strict Transport Security)
헤더:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
의미: "이후 1년간 절대 HTTP 로 접속하지 마. 무조건 HTTPS."
**preload**: Chrome HSTS preload 리스트에 등록 → 브라우저가 출하될 때부터 알고 있음.
9.2 HPKP 의 실패
Public Key Pinning 은 "내 도메인은 이 공개키만 믿어". 잘못 설정 시 사이트가 영구 죽음 → 너무 위험.
2018년 Chrome 이 HPKP 폐기. CT 가 같은 문제를 더 안전하게 해결.
9.3 CAA (Certificate Authority Authorization)
DNS 레코드:
example.com. CAA 0 issue "letsencrypt.org"
의미: "이 도메인에 대해 Let's Encrypt 만 인증서 발급 가능. 다른 CA 는 거절해야 함."
CA 가 발급 전 CAA 체크 의무화 (2017년부터). 실수/악성 CA 의 오발급 방지.
10. TLS 공격사 — 유명한 버그들
10.1 Heartbleed (2014)
OpenSSL 의 heartbeat 확장 버그. 클라이언트가 "16바이트 보냈으니 16바이트 돌려줘" 라고 요청하면서 실제로는 1바이트만 보냄 → 서버 메모리에서 16바이트 읽어 반환 → **메모리 덤프 유출**.
피해:
- 서버 개인키 유출.
- 사용자 세션, 비밀번호 노출.
- "인터넷 역사상 최악의 버그" 평가.
교훈: 오픈소스도 자금 없이는 보안 버그 쌓임 → Linux Foundation 의 Core Infrastructure Initiative 탄생.
10.2 BEAST (2011), POODLE (2014), Lucky 13 (2013)
CBC 모드의 patching 공격들. 순차적으로 cipher 위치가 무너지면서 **AEAD (GCM) 로의 전환** 이 가속화.
10.3 FREAK, Logjam (2015)
"export-grade 512-bit" 키 교환을 강제 다운그레이드하는 공격. 1990년대 미국 수출 규제의 유물이 15년 후 공격 벡터로 돌아옴.
교훈: 이전 모드 호환성을 남겨두면 **공격자가 그 모드로 다운그레이드** 시킴. TLS 1.3 이 과격하게 구식 제거한 이유.
10.4 DROWN (2016), Sweet32 (2016)
SSLv2 나 3DES 등 레거시 암호의 취약점을 이용. 아직도 일부 서버가 지원 → 현대 연결 공격 가능.
10.5 Raccoon (2020), ALPACA (2021)
TLS 1.2 의 마지막 공격들. TLS 1.3 에는 영향 없음. 업그레이드 동기.
11. 양자내성 암호 — 2024년의 긴급 사안
11.1 Harvest Now, Decrypt Later 위협
양자 컴퓨터가 2030년대 상용화될 가능성. Shor 의 알고리즘으로 RSA, ECC 모두 깨진다. 공격자는 **지금 트래픽을 녹화** 해두고 **양자 컴퓨터 나올 때 복호화** 할 수 있음.
"향후 30년간 비밀이어야 하는 데이터" (의료 기록, 국가 기밀) 는 **지금 당장** 양자 저항이 필요.
11.2 NIST PQC 표준화 (2024)
NIST 가 2016년 시작한 선정 프로세스의 결과 (2024 확정):
- **ML-KEM (Kyber)**: Key encapsulation. RSA/ECDHE 대체.
- **ML-DSA (Dilithium)**: 디지털 서명. ECDSA 대체.
- **SLH-DSA (SPHINCS+)**: 해시 기반 서명.
격자 기반 (lattice-based) 암호가 주력. 양자 컴퓨터에도 여전히 어려운 문제.
11.3 하이브리드 접근
기존 ECDH 와 새 Kyber 를 **동시에** 사용 → "둘 다 뚫려야 복호화 가능". 점진적 전환 전략.
key = HKDF(ECDH(x25519) || Kyber768)
11.4 Chrome 의 배포 (2024)
2024년 8월 Chrome 116+ 이 TLS 에 **X25519Kyber768** 하이브리드 기본 활성화:
- 핸드셰이크 크기 증가 (Kyber 공개키 1.2KB).
- 약 1ms 추가 CPU.
- 일부 미들박스 비호환 → "post-quantum bytes too large" 에러 → 일시적 롤백.
Cloudflare, AWS 도 비슷한 시기에 도입. TLS 사상 가장 큰 변화 중 하나.
11.5 남은 과제
- 서명 알고리즘 전환은 더 느림 (Dilithium 서명 3-5KB).
- IoT 장비의 Kyber 구현 부담.
- 인증서 체인 크기 증가 (수십 KB).
- PKI 전체 (Root CA, 증명서, CRL) 가 양자 안전으로 전환되려면 수년.
12. 실무 TLS — 점검표
12.1 서버 설정 (nginx 예시)
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 valid=300s;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
12.2 진단 도구
- **SSL Labs** (ssllabs.com): 종합 등급 A+ 목표.
- **testssl.sh**: 로컬에서 상세 분석.
- **Hardenize**: DNS, 이메일, 웹 보안 종합 검사.
- **Chrome DevTools > Security 탭**: 개발 중 빠른 확인.
12.3 성능 튜닝
- **OCSP Stapling**: 반드시 활성화.
- **HTTP/2 + TLS 1.3**: 가장 빠른 조합.
- **Session Resumption**: session ID 또는 session ticket. 1-RTT → 1-RTT 이후 0-RTT (TLS 1.3).
- **ECDSA 인증서**: RSA 보다 CPU 절감. 대부분 CA 지원.
12.4 모니터링
- **인증서 만료 알림**: 30일 전 알림 필수.
- **CT 로그 모니터링**: 자기 도메인의 새 인증서 알림 (crt.sh Watchtower, Cert Spotter).
- **TLS 버전 통계**: 특정 버전만 거부하는 클라이언트 파악.
13. 마치며 — 자물쇠의 역사가 말해주는 것
1994년 Netscape 의 허술한 SSL 1.0 에서 시작된 여정은 :
- **프로토콜 단순화**: 수백 cipher → 5개 core.
- **자동화**: 수작업 발급 → ACME 자동화.
- **투명성**: 블랙박스 CA → CT 공개 로그.
- **속도**: 2-RTT → 1-RTT → 0-RTT.
- **경제학**: 유료 → Let's Encrypt 무료.
- **안전성**: 큰 공격들의 피드백 루프.
그리고 2024년, 양자 컴퓨터라는 **전혀 새로운 차원의 위협** 때문에 전체 스택이 다시 움직이기 시작했다. 30년간 쌓인 인프라가 앞으로 10년 안에 양자 안전으로 재구축될 것이다.
자물쇠 아이콘 하나 뒤에는 이 모든 역사가 있다. 매번 HTTPS 연결할 때마다 수십 명의 수학자, 엔지니어, 표준화 위원회의 작업이 동시에 작동한다.
다음 글에서는 **JavaScript 엔진의 내부** — V8 의 hidden classes, TurboFan 최적화, Inline cache, 가비지 컬렉터, 그리고 왜 `for (let x of array)` 가 `for (let i = 0; i < array.length; i++)` 보다 때로는 빠른지 — 를 파볼 예정이다.
참고 자료
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3.
- RFC 8555 — Automatic Certificate Management Environment (ACME).
- Ivan Ristić — "Bulletproof SSL and TLS" (Feisty Duck, 2022 ed).
- Eric Rescorla — "SSL and TLS: Designing and Building Secure Systems" (고전).
- NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) — 2024 최종.
- Cloudflare 블로그 — TLS 1.3, Post-Quantum 시리즈.
- Mozilla Server Side TLS Guidelines.
- Let's Encrypt 기술 블로그.
- crt.sh — 인증서 투명성 검색.
- SSL Labs Best Practices.
현재 단락 (1/303)
브라우저 주소창 왼쪽의 작은 자물쇠. 사용자는 보통 2초도 보지 않고 지나간다. 그런데 그 자물쇠 뒤에는: