Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

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]                 ← 서버가 제시

브라우저는:

서버로부터 [google.com + Intermediate] 인증서 체인 수신.
Intermediate 의 공개키로 google.com 서명 검증.
Root CA 의 공개키로 Intermediate 서명 검증.
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가지 혁신

무료: 기부금 + 대기업 후원 (Mozilla, EFF, Akamai, Cisco 등).
자동화: ACME 프로토콜. certbot 명령 한 줄.
짧은 수명 (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.