오늘날 웹 브라우저 주소창의 자물쇠 아이콘은 너무나 익숙합니다. 우리는 이것이 '안전한 연결'을 의미한다고 알고 있으며, HTTPS가 웹 통신의 표준이 된 지 오래입니다. 하지만 이 자물쇠 뒤에는 어떤 기술이 숨어 있을까요? HTTPS는 정확히 어떻게 우리의 정보를 보호하며, 정말 '자물쇠'만 믿으면 모든 것이 안전할까요?
이 글에서는 웹 보안의 핵심인 HTTPS를 깊이 있게 파헤쳐 보겠습니다. 다음과 같은 내용을 다룹니다.
- HTTPS와 TLS의 기본 구조: 왜 HTTP만으로는 부족하며 TLS는 무엇을 하는가? (RFC 8446 등 기반)
- X.509 인증서와 CA(인증기관): 신뢰는 어떻게 만들어지고 검증되는가? (RFC 5280, CA/B Forum Baseline Requirements 기반)
- TLS 핸드셰이크 과정: 암호화 키는 어떻게 안전하게 교환되는가? (ASCII 다이어그램 포함)
- 실제 공격 시나리오: HTTPS를 사용해도 뚫릴 수 있는 경우는?
- 보안 강화를 위한 권장 사항: 사용자와 서버는 무엇을 해야 하는가?
특히 이 글에서는 왜 제3자인 CA(인증기관)가 필요한지, 그리고 이 신뢰 체계를 통해 우리가 무엇을 얻게 되는지 명확히 이해하는 데 초점을 맞춥니다. CA는 단순히 키 교환 중재자를 넘어, "통신하려는 서버의 신원을 확인하고, 그 신원과 해당 서버의 공개키를 X.509 표준에 따라 증명하는 디지털 인증서를 발급하여, 결과적으로 안전한 암호화 통신(특히 대칭키 교환)을 위한 신뢰의 출발점을 제공하는 기관"입니다.
1. HTTPS가 없다면? 평문 통신의 위험성
HTTPS가 왜 필요한지를 이해하려면, 그것이 없는 HTTP 통신의 문제를 먼저 알아야 합니다.
[Q&A – 1장 마무리]
- 교수: "학생, 만약 HTTPS가 없다면 웹 통신에서 어떤 위험이 가장 먼저 떠오르나요?"
- 학생: "통신 내용이 평문으로 전송되니, 중간에서 누군가 엿본다면 아이디, 비밀번호, 개인정보 등이 그대로 노출될 위험이 가장 큽니다. 데이터가 중간에 변조될 위험도 있고요."
- 교수: "맞습니다. HTTP는 ① 기밀성(Confidentiality)이 없어 엿듣기(Eavesdropping)에 취약하고, ② 무결성(Integrity) 보장이 안 돼 데이터 변조(Tampering)가 가능하며, ③ 서버가 진짜인지 인증(Authentication)할 방법이 없습니다. HTTPS는 이 세 가지 문제를 해결하기 위해 등장했습니다."
2. HTTPS 구조: TLS와 인증서라는 두 기둥
HTTPS는 사실 새로운 프로토콜이라기보다는, 기존의 HTTP 통신을 TLS라는 보안 계층 위에서 수행하는 방식입니다.
2.1. HTTPS = HTTP + TLS
- HTTP (HyperText Transfer Protocol): 웹 문서를 주고받기 위한 약속. 그 자체는 평문 통신입니다.
- TLS (Transport Layer Security): 전송 계층(TCP) 위에서 통신의 기밀성, 무결성, 인증을 제공하는 보안 프로토콜입니다. SSL(Secure Sockets Layer)의 후속 표준이며, 현재 TLS 1.3 (RFC 8446) 이 최신이고 TLS 1.2 (RFC 5246) 도 널리 쓰입니다. (TLS 1.0/1.1은 폐기됨 - RFC 8996)
- HTTPS (HTTP over TLS): HTTP 요청/응답을 TLS로 암호화하고, 서버 신원을 X.509 인증서로 검증합니다.
2.2. 인증서(SSL/TLS Certificate) & CA 체계: 신뢰의 기반
HTTPS의 핵심 중 하나는 '내가 접속한 서버가 정말 내가 접속하려는 그 서버가 맞는지' 확인하는 과정입니다. 이를 위해 디지털 인증서와 CA(인증기관) 시스템이 사용됩니다.
2.2.1. 인증서 기본 개념 (X.509 표준 기반)
- 정의: 특정 도메인/서버가 신뢰할 수 있는 제3자(CA)에 의해 신원이 확인되었음과 해당 서버의 공개키를 증명하는 RFC 5280 표준 기반의 전자 문서입니다.
- 주요 내용:
- 주체(Subject): 소유자 정보 (Common Name(CN) 또는 Subject Alternative Name(SAN)에 명시된 도메인 이름이 중요)
- 발급자(Issuer): 인증서를 발급한 CA의 이름
- 공개키(Public Key): 서버의 공개키 (데이터 암호화 및 서명 검증에 사용)
- 유효 기간(Validity Period): 인증서 사용 가능 기간
- CA의 디지털 서명(CA's Digital Signature): 이 인증서가 위변조되지 않았고, 해당 CA가 발급했음을 증명
2.2.2. CA(인증기관)의 역할과 신뢰 체계
- 역할: 웹사이트 운영자의 신원(특히 도메인 소유권)을 CA/Browser Forum의 Baseline Requirements 등 엄격한 기준에 따라 검증하고 인증서를 발급합니다. (예: DigiCert, Sectigo, Let's Encrypt)
- 신뢰 계층 (Trust Hierarchy):
- 루트 CA(Root CA): 최상위 기관. 이들의 인증서는 OS나 브라우저에 미리 내장되어 신뢰의 시작점이 됩니다.
- 중간 CA(Intermediate CA): 루트 CA가 신뢰성을 위임한 기관. 실제 서버 인증서는 주로 중간 CA가 발급합니다.
- 서버 인증서(End-entity Certificate): 최종 웹 서버에 발급되는 인증서.
- 브라우저는 서버 인증서 -> 중간 CA 인증서 -> ... -> 루트 CA 인증서 순서로 인증서 체인(Certificate Chain)을 따라가며, 최종적으로 내장된 루트 CA에 도달하는지 확인하여 신뢰성을 검증합니다.
- 검증 수준: DV(도메인 소유권만 확인, 자동화 용이), OV(조직 실존 확인), EV(더 엄격한 조직 검증) 등급이 있으며, 검증 수준이 높을수록 신뢰도가 높다고 간주됩니다.
2.2.3. 디지털 서명: 인증서를 믿을 수 있는 이유
- CA는 인증서 정보(주체, 공개키 등)를 해시합니다.
- CA는 이 해시값을 자신의 비밀키로 암호화하여 디지털 서명을 만듭니다.
- 인증서는 [인증서 정보 + CA 디지털 서명] 형태로 서버에 전달됩니다.
- 브라우저는 인증서를 받으면:
- 인증서 정보 부분을 동일하게 해시합니다 (결과 A).
- 인증서에 포함된 발급자(Issuer) 정보를 보고, 미리 내장된 해당 CA의 공개키를 찾습니다.
- 이 공개키로 CA의 디지털 서명을 복호화하여 원본 해시값(CA가 만들었던)을 얻습니다 (결과 B).
- A와 B를 비교합니다. 일치하면, 이 인증서는 서명한 CA가 발급한 것이 맞고, 내용이 위변조되지 않았음을 확신합니다.
[실제 사례: CA 신뢰 문제]
과거 Symantec, DigiNotar, Comodo 등의 CA에서 부적절한 인증서 발급이나 해킹 사건이 발생했습니다. 이로 인해 브라우저들은 해당 CA의 신뢰도를 낮추거나 완전히 제거하는 조치를 취했고, 이는 해당 CA로부터 인증서를 발급받은 수많은 웹사이트에 영향을 미쳤습니다. 이는 CA 시스템의 신뢰 유지가 얼마나 중요한지를 보여줍니다.
[Q&A – 2장 마무리]
- 교수: "브라우저가 서버로부터 받은 인증서를 검증할 때, 주로 어떤 것들을 확인하나요?"
- 학생: "네 가지 핵심 요소가 있습니다.
- 1) CA 서명 유효성: 신뢰하는 루트 CA까지 체인이 연결되고, 각 서명이 유효한지.
- 2) 유효 기간: 인증서가 만료되지 않았는지.
- 3) 도메인 일치: 접속하려는 URL의 도메인이 인증서의 CN 또는 SAN 필드에 포함되어 있는지.
- 4) 폐기 여부: 해당 인증서가 유효기간 전이라도 폐기(Revoked)되지 않았는지 (OCSP 또는 CRL 확인)."
- 교수: "정확합니다. 이 중 하나라도 문제가 있으면 브라우저는 사용자에게 강력한 보안 경고를 표시하게 됩니다."
3. TLS 핸드셰이크: 암호화 통신의 시작점
서버가 진짜임을 인증서로 확인했다면, 이제 클라이언트와 서버는 안전하게 통신할 방법을 마련해야 합니다. 여기서 TLS 핸드셰이크가 등장합니다.
3.1. 왜 대칭키 암호화가 필요한가?
- 공개키 암호화(비대칭키)는 키 교환이나 서명에는 강력하지만, 실제 데이터를 대량으로 암호화하기엔 느립니다.
- 대칭키 암호화는 매우 빠르지만, 통신 시작 전 양측이 안전하게 같은 키를 공유해야 하는 문제가 있습니다.
- TLS 핸드셰이크의 핵심 목표: 공개키 암호화 방식을 이용해 안전하게 임시 대칭키(세션 키)를 교환/생성하고, 이후 실제 데이터는 이 빠른 대칭키로 암호화하는 것입니다.
3.2. TLS 핸드셰이크 과정 (ASCII 다이어그램)
3.2.1. TLS 1.2 핸드셰이크 (ECDHE 키 교환 - Forward Secrecy 지원)
Forward Secrecy(순방향 비밀성)는 서버의 장기 비밀키가 유출되어도 과거 통신 내용이 보호되는 중요한 기능입니다. ECDHE 방식은 이를 가능하게 합니다.
Client (Browser) Server
| |
| --- ClientHello -----------------------------> | // 1. 클라이언트 시작: 지원 버전, 암호 스위트, 랜덤값 등 전송
| (TLS 1.2, Cipher Suites(ECDHE 포함), Random1) |
| |
| <---------------------------- ServerHello ------ | // 2. 서버 응답: 선택된 버전, 암호 스위트, 랜덤값2
| (TLS 1.2, ECDHE Suite, Random2)
| <---------------------------- Certificate ------ | // 3. 서버 인증서 전송
| (Server's X.509 Cert)
| <-------------------------- ServerKeyExchange -- | // 4. ECDHE 파라미터, 서버의 임시 공개키 + 서명 전송
| (Curve Params, Server Ephemeral PubKey, Signature)
| <-------------------------- ServerHelloDone ---- | // 5. 서버 메시지 끝
| |
| === 클라이언트 작업 === | // - 인증서 검증, 서명 검증
| | // - 클라이언트 임시 키쌍 생성
| | // - 서버 임시 공개키와 조합 -> 공유 비밀 (PreMasterSecret) 계산
| | // - 공유 비밀 + 랜덤값들 -> 세션 키 생성
| |
| --- ClientKeyExchange ------------------------> | // 6. 클라이언트의 임시 공개키 전송
| (Client Ephemeral PubKey) |
| --- ChangeCipherSpec -------------------------> | // 7. 지금부터 암호화 시작 알림
| --- Finished (Encrypted) ---------------------> | // 8. 핸드셰이크 내용 해시 (암호화됨)
| |
| === 서버 작업 === | // - 클라이언트 임시 공개키 수신
| | // - 클라이언트 임시 공개키와 조합 -> 공유 비밀 계산
| | // - 세션 키 생성
| | // - 클라이언트 Finished 검증
| |
| <-------------------------- ChangeCipherSpec --- | // 9. 서버도 암호화 시작 알림
| <-------------------------- Finished (Encrypted) | // 10. 서버 핸드셰이크 내용 해시 (암호화됨)
| |
| ============ 핸드셰이크 완료 / 암호화 통신 시작 ============ |
| |
| --- Application Data (Encrypted) -------------> | // 11. HTTP 요청 (암호화)
| <---------------- Application Data (Encrypted) ---| // 12. HTTP 응답 (암호화)
3.2.2. TLS 1.3 핸드셰이크
TLS 1.3은 속도와 보안을 더욱 개선했습니다. 핸드셰이크 왕복 횟수를 줄이고, 더 많은 부분을 암호화하며, Forward Secrecy가 기본입니다.
Client (Browser) Server
| |
| --- ClientHello -----------------------------> | // 1. 클라이언트 시작: TLS 1.3, 암호 스위트, 랜덤값1, *키 공유 정보(임시 공개키)*
| (TLS 1.3, Cipher Suites, Random1, Key Share) |
| |
| <---------------------------- ServerHello ------ | // 2. 서버 응답: TLS 1.3, 선택된 스위트, 랜덤값2, *서버 키 공유 정보*
| (TLS 1.3, Suite, Random2, Key Share)
| |
| === 양측, 공유 비밀 계산 & 세션 키 생성 === | // (핸드셰이크 암호화 키 & 실제 데이터 암호화 키 분리 생성)
| |
| <------- [Encrypted Extensions] (암호화) ------ | // 3. 서버 추가 정보 (암호화)
| <------- [Certificate] (암호화) --------------- | // 4. 서버 인증서 (암호화!)
| <------- [CertificateVerify] (암호화) --------- | // 5. 서버 인증서 소유 증명 (암호화)
| <------- [Finished] (암호화) ------------------ | // 6. 서버 핸드셰이크 해시 (암호화)
| |
| === 클라이언트 작업 === | // - 서버 인증서/서명 검증, Finished 검증
| |
| ------> [Finished] (암호화) --------------------| // 7. 클라이언트 핸드셰이크 해시 (암호화)
| |
| ============ 핸드셰이크 완료 / 암호화 통신 시작 ============ |
| |
| ------> Application Data (Encrypted) -----------| // 8. HTTP 요청 (암호화)
| <------ Application Data (Encrypted) -----------| // 9. HTTP 응답 (암호화)
[Q&A – 3장 마무리]
- 교수: "만약 중간자(공격자)가 TLS 핸드셰이크 과정에서 키 교환 메시지(예: ClientKeyExchange 또는 Key Share)를 가로챈다면, 대칭 세션 키를 알아낼 수 있을까요?"
- 학생: "아니요. (TLS 1.2 RSA 방식이었다면) Pre-Master Secret은 서버의 공개키로 암호화되므로 서버 비밀키 없이는 복호화가 불가능합니다. (TLS 1.2/1.3의 ECDHE 방식에서는) 교환되는 것은 임시 공개키들이며, 이 값들을 가로채더라도 개인키 없이는 최종 공유 비밀(세션 키 생성의 기초)을 계산할 수 없습니다. 이것이 키 교환의 핵심 보안입니다."
- 교수: "정답입니다. 그리고 TLS 1.3과 ECDHE가 제공하는 Forward Secrecy 덕분에, 설령 나중에 서버의 장기 비밀키(인증서 내 공개키의 쌍)가 유출되더라도, 각 통신 세션에 사용된 임시 세션 키는 안전하게 보호된다는 점도 중요합니다."
4. HTTPS는 만능일까? 숨겨진 보안 문제들
자물쇠가 있다고 해서 모든 위협이 사라지는 것은 아닙니다.
HTTPS 통신 자체는 안전할지 몰라도, 다른 약점을 파고드는 공격은 여전히 존재합니다.
4.1. 중간자 공격(MITM) 우회 시나리오
- 악성 루트 CA 설치: 사용자의 기기가 악성코드에 감염되어 공격자의 가짜 루트 CA가 '신뢰할 수 있는 기관' 목록에 설치되면, 브라우저는 공격자가 발급한 가짜 웹사이트 인증서(예: 가짜 google.com)를 정상으로 인식합니다. 공격자는 사용자와 실제 서버 사이에서 프록시 역할을 하며 모든 HTTPS 트래픽을 복호화하고 엿보거나 조작할 수 있습니다.
- (합법적 MITM?) 일부 기업 보안 솔루션이나 공공 와이파이는 트래픽 검사/필터링 목적으로 자체 CA를 설치하고 유사한 방식으로 HTTPS를 '해독'하기도 합니다. 이는 관리 목적이지만, 사용자 동의 및 인지가 중요합니다.
- 실제 사례: Dell eDellRoot, Superfish 사건은 제조사가 PC에 자체 루트 CA를 사전 설치하면서 발생한 보안 문제로 큰 파장을 일으켰습니다.
4.2. CA 자체의 보안 문제
- CA 해킹 또는 운영 미흡: 만약 CA의 인증서 발급 시스템이 해킹당하거나 내부 통제가 부실하면, 공격자가 주요 웹사이트에 대한 가짜 인증서를 발급받을 수 있습니다.
- DigiNotar (2011) 사건: 해킹으로 구글 등 수백 개 도메인의 위조 인증서가 발급되어 실제 공격에 악용되었고, 결국 해당 CA는 파산하고 브라우저에서 신뢰가 철회되었습니다.
- 이런 사건은 전체 인터넷 신뢰 시스템에 큰 타격을 주며, 브라우저 벤더들은 문제의 CA를 신뢰 목록에서 제거하는 긴급 조치를 취합니다.
4.3. 피싱(Phishing) 사이트의 HTTPS 남용
- 가장 흔한 오해: "자물쇠가 있으니 이 사이트는 안전하다."
- 현실: 공격자들도 Let's Encrypt 등 무료/자동화된 DV 인증서를 이용해 피싱 사이트에 HTTPS를 쉽게 적용합니다. secure-login-web-google.com 같은 교묘한 도메인에 유효한 인증서를 받아 사용자를 속입니다.
- 기억하세요: 자물쇠는 '내 브라우저와 이 서버 간의 통신이 암호화되었다' 와 '접속한 도메인이 인증서에 명시된 도메인과 일치한다' 는 기술적 사실만을 의미할 뿐, '이 사이트 운영 주체가 신뢰할 만하다' 는 것을 보장하지 않습니다.
4.4. 클라이언트 및 서버 자체의 취약점
- 클라이언트 측:
- Man-in-the-Browser: 악성 브라우저 확장 프로그램 등에 의해 브라우저 자체가 감염되면, HTTPS 통신이 복호화된 후 사용자에게 보여지기 전에 데이터(입력값 등)가 탈취되거나 변조될 수 있습니다.
- OS/브라우저 취약점: 구버전 소프트웨어 사용은 알려진 보안 허점을 통해 공격자에게 침투 경로를 제공합니다.
- 서버 측:
- 웹 애플리케이션 취약점: 서버에 SQL Injection, XSS, 설정 오류 등이 존재하면, HTTPS로 전송 구간을 아무리 잘 보호해도 서버의 데이터베이스가 털리거나 악성 코드가 삽입될 수 있습니다.
- 서버 비밀키 유출: 서버 관리 부실로 인증서의 비밀키가 유출되면, (Forward Secrecy가 없는 경우) 저장된 과거 트래픽을 복호화당할 위험이 있습니다.
[Q&A – 4장 마무리]
- 교수: "HTTPS 통신이 완벽한 보안을 보장하지 못하는 이유, 대표적인 사례 세 가지를 들어볼까요?"
- 학생: "첫째, 악성 CA 설치나 CA 자체 해킹으로 인한 MITM 공격 가능성. 둘째, 피싱 사이트도 유효한 HTTPS를 쉽게 사용한다는 점. 셋째, 통신 구간은 안전해도 사용자의 브라우저나 웹 서버 자체가 다른 취약점으로 공격당하는 경우입니다."
- 교수: "정확합니다. HTTPS는 필수적인 보안 계층이지만, 엔드포인트(사용자, 서버) 보안과 신뢰 체계(CA) 관리가 함께 이루어져야 진정한 안전을 기대할 수 있습니다."
5. 안전한 웹 사용을 위한 권장사항 & 마무리
HTTPS의 한계를 이해했다면, 우리는 어떻게 더 안전하게 웹을 사용할 수 있을까요? 사용자와 서버 관리자 모두 노력해야 할 부분이 있습니다.
5.1. 사용자 측면
- 인증서 경고 무시 금지: 브라우저가 "연결이 비공개로 설정되어 있지 않음" 등의 경고를 보낸다면, 절대 무시하고 접속하지 마세요. 잠재적 위험 신호입니다.
- URL 꼼꼼히 확인: 자물쇠만 보지 말고, 주소창의 도메인 철자가 정확한지, 의심스러운 부분이 없는지 항상 확인하는 습관을 가지세요. 특히 로그인이나 개인 정보 입력 시 더욱 주의해야 합니다.
- OS 및 브라우저 최신 상태 유지: 최신 업데이트는 알려진 보안 취약점을 해결하고 최신 보안 기술(TLS 1.3 등)을 지원합니다.
5.2. 서버 관리자 측면
- 강력한 TLS 설정:
- 최신 TLS 버전(1.3 우선, 최소 1.2)만 사용하도록 서버를 구성합니다. (TLS 1.0, 1.1 비활성화)
- 안전한 암호 스위트(Cipher Suite)만 사용하고, 취약한 알고리즘(RC4, 3DES, MD5, SHA-1 등)은 제거합니다.
- Forward Secrecy(순방향 비밀성)를 지원하는 키 교환 방식(ECDHE)을 활성화합니다.
- HSTS (HTTP Strict Transport Security, RFC 6797) 적용: 브라우저에게 해당 사이트는 무조건 HTTPS로만 접속해야 한다고 알리는 헤더입니다. HTTP 접속 시도 및 SSL Stripping 공격을 방지합니다. max-age를 길게 설정하고, includeSubDomains, preload 지시어 사용을 고려하세요.
- Certificate Transparency (CT, RFC 6962/9162) 준수: 발급된 모든 인증서를 공개 로그에 기록하여, 악의적이거나 잘못 발급된 인증서를 빠르게 탐지할 수 있도록 합니다. 주요 브라우저는 CT 정보를 요구합니다.
- 서버 비밀키 철저 관리: 비밀키 접근 권한을 최소화하고 안전하게 보관하며, 정기적으로 교체하는 것을 고려합니다.
- 정기적인 보안 점검: SSL Labs의 SSL Test 같은 도구를 사용하여 서버의 HTTPS/TLS 설정을 점검하고 취약점을 개선합니다.
[Q&A – 5장 마무리]
- 교수: "학생, 이제 정리해 봅시다. 우리가 웹사이트에 접속할 때 HTTPS를 사용한다고 해서 100% 안심해도 될까요?"
- 학생: "아니요. HTTPS는 통신 채널 보안의 필수 요소이지만, 그 자체로 완전한 방패는 아닙니다. CA 시스템의 신뢰성, 사용자의 주의(피싱 등), 클라이언트/서버 시스템 자체의 보안 상태 등 여러 요소가 함께 중요합니다. 종합적인 보안 관리가 필요합니다."
- 교수: "맞습니다. 이 글을 통해 전달하고 싶었던 핵심 메시지입니다. HTTPS는 필수지만 만능은 아니며, 보안은 여러 계층에서 함께 노력해야 한다는 점입니다."
결론
HTTPS (= HTTP + TLS)는 현대 웹 통신의 기본 보안입니다. X.509 인증서와 CA 시스템은 우리가 접속하려는 서버의 신원을 확인하는 신뢰의 근간을 제공하며, TLS 핸드셰이크는 이 신뢰를 바탕으로 암호화 통신에 사용할 대칭 세션 키를 안전하게 교환하는 기술적 과정입니다.
하지만 CA 해킹, 악성 CA 설치, HTTPS를 악용한 피싱, 엔드포인트 취약점 등 다양한 위협이 존재하므로, 자물쇠 아이콘만 보고 안심해서는 안 됩니다. 사용자는 인증서 경고에 주의하고 URL을 확인하며 시스템을 최신 상태로 유지해야 합니다. 서버 관리자는 최신 TLS 설정, HSTS, CT, Forward Secrecy 등 현대적인 보안 기술을 적극적으로 적용하고 관리해야 합니다.
HTTPS는 선택이 아닌 필수이지만, 그 자체로 모든 보안 문제가 해결되지는 않습니다. 모든 시스템의 보안은 결국 **"가장 약한 연결 고리의 강도에 의해 결정된다"**는 사실을 잊지 말아야 합니다.
※ 참고 자료:
- IETF RFC 5246 (The Transport Layer Security (TLS) Protocol Version 1.2)
- IETF RFC 8446 (The Transport Layer Security (TLS) Protocol Version 1.3)
- IETF RFC 5280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile)
- IETF RFC 6797 (HTTP Strict Transport Security (HSTS))
- IETF RFC 6962 / RFC 9162 (Certificate Transparency)
- IETF RFC 8996 (Deprecating TLS 1.0 and TLS 1.1)
- CA/Browser Forum Baseline Requirements
- OWASP (Open Web Application Security Project) - TLS Cipher String Cheat Sheet, Transport Layer Protection Cheat Sheet 등
끝까지 읽어주셔서 감사합니다. HTTPS와 웹 보안에 대해 더 궁금한 점이 있다면 언제든 댓글로 질문해주세요!
'네트워크 > 네트워크 기초' 카테고리의 다른 글
| ARP: IP 주소로 옆자리 친구(MAC 주소) 찾아가기 (0) | 2025.04.08 |
|---|---|
| 3계층 (네트워크) 개요: 다른 동네까지 길 찾아가기 (IP 주소, 라우팅) (0) | 2025.04.08 |
| 2계층 (데이터 링크): 바로 옆 장비와 통신하는 방법 (이더넷, MAC 주소) (0) | 2025.04.08 |
| 네트워크 모델와 데이터 단위 (TCP/IP 모델, OSI 7계층, 패킷, PDU) (0) | 2025.04.08 |
| JWT(JSON Web Token) 심층 분석: Stateless 인증의 이해와 안전한 사용 전략 (0) | 2025.04.03 |