Notes

TLS는 왜 IP가아닌 도메인을 통해야하는가?

33 min read

TLS 하려면 그냥 ip로접속하면 안되는 이유

아주 좋은 질문입니다. 기술적인 핵심을 짚는 질문이네요.

TLS를 사용하려면 IP 주소로 직접 접속하면 안 되는 이유를 한마디로 요약하면, “TLS 인증서는 IP 주소가 아닌 도메인 이름의 소유권을 증명하기 때문”입니다.

조금 더 쉽게 이해할 수 있도록 비유와 함께 자세히 설명해 드리겠습니다.

쉬운 비유: 가게와 사업자등록증

  • IP 주소: 가게의 실제 주소 (예: 서울시 강남구 테헤란로 123)
  • 도메인 이름: 가게의 상호 (예: ‘맛있는 코딩 카페’)
  • TLS 인증서: 가게의 ‘사업자등록증’

손님(사용자)이 가게를 찾아갈 때, 주소(IP)만 보고 찾아갈 수도 있습니다. 하지만 그 가게가 정말 내가 찾던 ‘맛있는 코딩 카페’(도메인)가 맞는지, 그리고 믿을 수 있는 곳인지 어떻게 알 수 있을까요?

이때 ‘사업자등록증’(TLS 인증서)을 확인합니다. 사업자등록증에는 **“이 가게의 상호는 ‘맛있는 코딩 카페’가 맞습니다”**라고 명시되어 있습니다.

만약 손님이 주소(IP)만 가지고 가게에 도착해서 사업자등록증을 봤는데, 거기에는 ‘맛있는 코딩 카페’라고 쓰여있다면, 손님(브라우저)은 이렇게 생각합니다.

“어? 나는 그냥 주소(192.0.2.1)만 보고 찾아왔는데, 이 가게는 자기가 ‘맛있는 코딩 카페(example.com)‘라고 주장하네? 내가 원래 가려던 곳이 맞는지 확인할 길이 없으니 위험할 수 있겠다!”

이것이 바로 브라우저가 IP 주소로 접속했을 때 “안전하지 않은 연결” 경고를 띄우는 이유입니다.

기술적인 이유 (3가지 핵심)

1. 인증서의 본질: 신원 확인 (Identity Verification)

TLS의 가장 중요한 역할 중 하나는 암호화뿐만 아니라 ‘내가 접속한 서버가 진짜 그 서버가 맞는지’를 확인하는 것입니다.

  • TLS 인증서는 공인된 인증 기관(CA, Certificate Authority)이 발급합니다.
  • CA는 인증서를 발급할 때, **“이 도메인(예: www.google.com)은 구글이 소유한 것이 맞다”**는 사실을 검증하고 인증서에 ‘도장’을 찍어줍니다. IP 주소의 소유권을 검증하는 경우는 거의 없습니다.
  • 사용자의 웹 브라우저는 서버에 접속할 때 이 인증서를 받아서, ① CA가 신뢰할 만한 곳인지, ② 인증서가 만료되지 않았는지, 그리고 가장 중요하게 ③ 내가 접속하려는 도메인 주소와 인증서에 적힌 도메인 주소가 일치하는지를 확인합니다.

IP 주소로 접속하면, 브라우저가 접속하려는 주소(예: 142.250.196.142)와 인증서에 적힌 주소(www.google.com)가 다르기 때문에 “신원 불일치”로 판단하고 경고를 보냅니다.

2. 가상 호스팅과 SNI (Server Name Indication)

요즘 웹 서버는 하나의 IP 주소로 수십, 수백 개의 다른 웹사이트(도메인)를 운영하는 경우가 대부분입니다. 이를 ‘가상 호스팅’이라고 합니다.

  • 서버 입장: 클라이언트(브라우저)가 IP 주소로만 접속 요청을 보내면, 이 요청이 a.com을 위한 것인지, b.com을 위한 것인지 알 길이 없습니다. 수많은 웹사이트 중 어떤 사이트의 TLS 인증서를 보내줘야 할까요?
  • SNI 기술: 이 문제를 해결하기 위해 나온 것이 SNI(서버 이름 표시)입니다. 브라우저는 TLS 통신을 시작하는 첫 단계(Handshake)에서 “나 www.google.com에 접속하고 싶어”라고 서버에 도메인 이름을 알려줍니다.
  • 서버의 응답: 서버는 이 SNI 정보를 보고 “아, www.google.com 용 인증서를 보내주면 되겠구나!”라고 판단하여 올바른 인증서를 클라이언트에게 전달합니다.

만약 IP 주소로 접속하면 브라우저가 SNI 정보를 보낼 수 없으므로, 서버는 어떤 인증서를 줘야 할지 몰라 기본 인증서를 보내거나 오류를 발생시킵니다.

3. IP 주소의 유동성

서버의 IP 주소는 고정되어 있지 않고 바뀔 수 있습니다. (서버 이전, 클라우드 환경의 변화 등)

  • 만약 인증서가 IP 주소에 묶여 있다면, IP가 바뀔 때마다 비싼 돈을 들여 인증서를 재발급받아야 합니다. 이는 매우 비효율적입니다.
  • 반면 도메인 이름은 소유자가 바뀌지 않는 한 거의 변하지 않는 고유한 식별자입니다. 따라서 도메인에 인증서를 발급하는 것이 훨씬 안정적이고 관리하기 편리합니다.

예외도 있나요?

  • IP 주소용 인증서: 기술적으로는 IP 주소에 대한 인증서를 발급받는 것이 가능합니다. 하지만 절차가 복잡하고 비용이 비싸며, 대부분의 CA는 잘 발급해주지 않습니다. 일반적인 웹 환경에서는 거의 사용되지 않습니다.
  • 자체 서명 인증서(Self-signed Certificate): 개발 환경이나 내부망에서는 공인 CA가 아닌 내가 직접 만든 ‘자체 서명 인증서’를 사용하기도 합니다. 이 경우 IP 주소를 넣어서 만들 수는 있지만, 브라우저는 당연히 “신뢰할 수 없는 기관이 발급한 인증서”라며 경고를 띄웁니다.

결론

TLS는 단순히 데이터를 암호화하는 것을 넘어, ‘신뢰할 수 있는 상대방’과 통신하고 있음을 보장하는 기술입니다. 이 ‘신뢰’는 유동적이고 익명적인 IP 주소가 아닌, 소유권이 명확한 도메인 이름을 기준으로 구축됩니다. 따라서 안전한 TLS 통신을 위해서는 반드시 도메인 이름으로 접속해야 합니다.

TLS 는 브라우저에서만 동작하는지? 그리고 그냥 ip로 요청을하면 헤더가 어떻게 되지 도메인을 쓴것과의 차이. 테스트용으로 윈도우 hosts에 직접 ip를 도멩ㄴ과 매핑중임

네, 아주 좋은 후속 질문입니다. 사용자가 직접 테스트하면서 궁금해할 만한 핵심적인 내용들을 정확히 짚어주셨네요.

1. TLS는 브라우저에서만 동작하는가?

결론부터 말씀드리면, 절대 아닙니다.

TLS(Transport Layer Security)는 특정 애플리케이션(브라우저)에 종속된 기술이 아니라, 네트워크 통신을 암호화하기 위한 표준 프로토콜입니다. 따라서 네트워크 통신을 하는 거의 모든 종류의 애플리케이션에서 사용될 수 있습니다.

브라우저 외에 TLS가 사용되는 대표적인 예시:

  • API 클라이언트/서버: 서버와 서버 간의 API 통신, 또는 앱/프로그램이 서버의 API를 호출할 때 데이터 유출을 막기 위해 사용됩니다. (curl, Postman 같은 도구들도 당연히 TLS를 지원합니다.)
  • 모바일 앱: 스마트폰 앱이 백엔드 서버와 데이터를 주고받을 때 사용자의 개인정보(로그인 정보, 결제 정보 등)를 보호하기 위해 필수적으로 사용됩니다.
  • 이메일 클라이언트: Outlook, Thunderbird 같은 이메일 프로그램이 메일 서버(Gmail, Naver 등)와 통신할 때 (SMTP/IMAP/POP3 over TLS/SSL)
  • 데이터베이스 연결: 원격 데이터베이스에 접속할 때 접속 정보와 쿼리 내용 등을 암호화하기 위해 사용됩니다.
  • FTP 클라이언트: FTPS (FTP over TLS)를 사용하여 파일 전송을 암호화합니다.
  • 그 외에도 VPN, 메시징 앱 등 보안이 필요한 모든 통신에 사용됩니다.

TLS는 애플리케이션 계층(HTTP, SMTP 등)과 전송 계층(TCP) 사이에서 동작하며, 애플리케이션이 주고받는 데이터를 투명하게 암호화해주는 역할을 합니다.

2. IP vs 도메인 요청 시 헤더 차이 (hosts 파일 사용 시나리오 포함)

이 부분이 사용자의 테스트와 직접적으로 관련된 아주 중요한 포인트입니다. hosts 파일을 사용하는 것은 이 차이를 이해하는 데 최고의 방법 중 하나입니다.

결론적으로, IP로 접속하느냐 도메인으로 접속하느냐에 따라 TLS Handshake의 SNI(Server Name Indication) 정보와 HTTP 요청의 Host 헤더 값이 달라집니다.

아래 3가지 시나리오를 비교해 보겠습니다. (가상 IP: 1.2.3.4, 도메인: my-test.com)

시나리오 1: 도메인으로 정상 접속 (https://my-test.com)

  1. DNS 조회: PC가 DNS 서버에 my-test.com의 IP 주소를 물어보고 1.2.3.4를 응답받습니다.
  2. TLS Handshake (통신 시작):
    • 브라우저는 1.2.3.4 IP를 가진 서버에 접속을 시도합니다.
    • 이때 SNI 필드에 my-test.com 이라는 도메인 이름을 담아서 보냅니다.
    • 서버는 SNI 값을 보고 “아, my-test.com에 대한 요청이구나!”라고 인지하고, my-test.com에 맞는 TLS 인증서를 브라우저에 보내줍니다.
  3. HTTP 요청 (암호화된 통신 내부):
    • TLS 연결이 성공적으로 수립되면, 그 안으로 실제 HTTP 요청을 보냅니다.
    • 이때 HTTP Host 헤더 값은 my-test.com 이 됩니다.
    • 서버는 Host 헤더를 보고 my-test.com에 맞는 웹 콘텐츠(HTML, 이미지 등)를 응답합니다.

시나리오 2: IP 주소로 직접 접속 (https://1.2.3.4)

  1. DNS 조회: 필요 없음.
  2. TLS Handshake:
    • 브라우저는 1.2.3.4 IP를 가진 서버에 접속을 시도합니다.
    • 보낼 도메인 이름이 없으므로 SNI 필드가 비어 있거나, IP 주소(1.2.3.4)가 포함됩니다.
    • 서버는 어떤 도메인에 대한 요청인지 알 수 없으므로, 설정된 기본(default) 인증서를 보내거나 오류를 반환합니다. 이 인증서는 대부분의 경우 1.2.3.4라는 이름으로 발급된 것이 아니므로 브라우저는 “인증서 이름 불일치” 경고를 띄웁니다.
  3. HTTP 요청:
    • (경고를 무시하고 연결했다면) HTTP Host 헤더 값은 1.2.3.4 가 됩니다.
    • 서버는 Host 헤더의 IP 주소를 보고, 해당하는 웹사이트를 찾지 못해 기본 페이지나 오류 페이지를 보여줍니다.

시나리오 3: hosts 파일에 매핑 후 도메인으로 접속 (사용자님의 현재 테스트 상황)

  • C:\Windows\System32\drivers\etc\hosts 파일에 1.2.3.4 my-test.com 추가
  • 브라우저 주소창에 https://my-test.com 입력
  1. DNS 조회: 브라우저는 DNS 서버에 묻기 전에 hosts 파일을 먼저 확인합니다. hosts 파일에서 my-test.com이 1.2.3.4에 매핑된 것을 발견하고, 1.2.3.4로 접속을 시도합니다.
  2. TLS Handshake:
    • 브라우저는 **목적지 IP는 1.2.3.4**로 설정하지만, **사용자가 입력한 도메인이 my-test.com**이라는 것을 알고 있습니다.
    • 따라서 SNI 필드에 **my-test.com**을 담아서 보냅니다.
  3. HTTP 요청:
    • TLS 연결이 수립된 후, HTTP Host 헤더 값 역시 **my-test.com**으로 설정하여 보냅니다.

결론 및 요약:

접속 방식접속 대상 IPTLS Handshake (SNI)HTTP Host 헤더서버의 동작
도메인 접속 (https://my-test.com)1.2.3.4 (DNS)my-test.commy-test.comSNI와 Host 헤더를 보고 my-test.com에 맞는 인증서와 콘텐츠를 정상적으로 제공. (성공)
IP 직접 접속 (https://1.2.3.4)1.2.3.4(없음) 또는 1.2.3.41.2.3.4어떤 도메인인지 몰라 기본 인증서/페이지를 제공. 브라우저에서 인증서 경고 발생. (실패 또는 경고)
hosts 파일 사용 (https://my-test.com)1.2.3.4 (hosts)my-test.commy-test.com’도메인 접속’과 완전히 동일하게 동작. 서버는 1.2.3.4에서 my-test.com 요청을 정상적으로 처리.

사용자님께서 hosts 파일에 IP와 도메인을 매핑하는 것은 **“DNS 서버를 내 컴퓨터로 가져와서 특정 도메인에 대한 응답을 강제로 지정하는 것”**과 같습니다. 따라서 브라우저와 서버 입장에서는 일반적인 도메인 접속과 완전히 동일하게 동작하며, TLS 통신을 테스트하는 매우 효과적이고 올바른 방법입니다.

그런데 DNS에서 이 도메인이름과 ip주소를 맘대로 할수있잖아? 혹시 그래서 공인된 인증서의 경우는 공인된 DNS서버에서온것만 그게 안전한지 판단하는건가?

네, 아주 정확하고 날카로운 지적입니다. 그 부분이 바로 DNS 스푸핑(DNS Spoofing) 공격과 TLS 인증서의 역할이 교차하는 지점입니다.

결론부터 말씀드리면, TLS 인증서는 DNS 서버의 신뢰성과는 별개로, 최종적으로 접속한 서버의 신원을 독립적으로 검증하는 역할을 합니다. 즉, DNS가 속더라도 TLS가 마지막 방어선이 되어주는 것입니다.

사용자님의 질문을 풀어 설명하면 이렇습니다.

“공격자가 DNS 서버를 해킹하거나 중간에서 DNS 응답을 가로채서 www.mybank.com의 IP 주소를 진짜 은행 서버가 아닌, 자신의 가짜 피싱 서버 IP로 알려주면 어떡하지? 브라우저는 속아서 가짜 서버로 접속할 텐데, 이때 TLS는 어떻게 동작하는가?”

이 시나리오를 통해 TLS의 진짜 힘을 알 수 있습니다.

DNS 스푸핑 공격 시나리오

  1. 사용자: 브라우저에 https.www.mybank.com 입력
  2. 브라우저: PC의 DNS 리졸버에게 “www.mybank.com의 IP 주소 좀 알려줘.” 라고 요청
  3. 공격자 (DNS 스푸핑): 중간에서 DNS 응답을 가로채거나, 변조된 DNS 서버가 응답합니다.
    • 정상 응답: 11.22.33.44 (진짜 은행 서버 IP)
    • 공격자의 가짜 응답: 99.88.77.66 (공격자가 만든 피싱 서버 IP)
  4. 브라우저: 공격자가 보낸 가짜 IP(99.88.77.66)를 진짜인 줄 믿고, 해당 IP로 접속을 시도합니다.

이제 여기서부터 TLS가 방어막 역할을 합니다.

TLS의 방어 메커니즘

  1. 브라우저 (TLS Handshake 시작):

    • 99.88.77.66 (피싱 서버)에 접속합니다.
    • 이때 브라우저는 자기가 접속하려는 도메인이 **www.mybank.com**이라는 것을 정확히 기억하고 있습니다.
    • 그래서 TLS Handshake 과정에서 SNI 정보에 www.mybank.com을 담아 피싱 서버에 보냅니다. “안녕? 나 www.mybank.com에 접속하러 왔어. 너의 신원을 증명해봐.”

  2. 피싱 서버의 곤경:

    • 피싱 서버는 www.mybank.com에 대한 공인된 TLS 인증서를 가지고 있지 않습니다.
    • 공인 인증 기관(CA)은 www.mybank.com이라는 도메인의 소유권을 증명할 수 있는 진짜 은행에게만 인증서를 발급해 주기 때문입니다. 공격자는 이 도메인의 소유권을 증명할 방법이 없습니다.

  3. 피싱 서버의 선택과 브라우저의 반응 (3가지 경우):

    • Case 1: 아무 인증서나 보낸다 (예: www.evil-site.com 인증서)

      • 브라우저는 받은 인증서를 확인하고 외칩니다. “내가 접속하려는 곳은 www.mybank.com인데, 네가 제시한 인증서는 www.evil-site.com용이잖아! 이름이 달라! 이건 사기야!”
      • ➡️ “NET::ERR_CERT_COMMON_NAME_INVALID” 와 같은 심각한 보안 경고를 띄우고 페이지 연결을 차단합니다.

    • Case 2: 자체 서명(Self-signed)된 www.mybank.com 인증서를 만들어 보낸다.

      • 브라우저는 인증서를 보고 “이 인증서는 www.mybank.com용이 맞긴 한데… 발급자(CA)를 보니 Comodo, Let’s Encrypt 같은 우리가 신뢰하는 공인 기관이 아니라, 그냥 네가 직접 만들었네? 이걸 어떻게 믿어?” 라고 판단합니다.
      • ➡️ “NET::ERR_CERT_AUTHORITY_INVALID” 와 같은 심각한 보안 경고를 띄우고 연결을 차단합니다.

    • Case 3: 아예 TLS 통신에 응답하지 않거나, 잘못된 응답을 한다.

      • 브라우저는 일정 시간 동안 기다리다 응답이 없으면 연결 실패(Timeout) 오류를 띄웁니다.
      • ➡️ “연결할 수 없음” 또는 “SSL_ERROR_…” 등의 오류를 표시합니다.

결론: DNS와 인증서는 독립적인 신뢰 체인

  • DNS: ‘이름표’를 보고 ‘집 주소’를 찾아주는 역할입니다. 이 ‘집 주소’ 정보는 중간에 변조될 수 있습니다.
  • TLS 인증서: 찾아간 ‘집’의 문 앞에서 ‘집문서(소유권 증명서)‘를 확인하는 역할입니다. 집 주소가 맞게 찾아왔든 틀리게 찾아왔든 상관없이, 그 집의 ‘소유자 이름(도메인)‘이 내가 찾던 그 ‘이름’과 일치하는지, 그리고 그 ‘집문서’가 신뢰할 수 있는 ‘등기소(CA)‘에서 발급한 것인지를 독립적으로 검증합니다.

따라서 “공인된 DNS 서버에서 온 것만 안전한지 판단하는가?” 라는 질문에 대한 답은 “아니요, 그렇지 않습니다.” 입니다.

TLS는 DNS가 어떤 상태이든 상관없이, 브라우저가 접속한 최종 서버가 브라우저가 원래 접속하려 했던 그 도메인의 합법적인 소유자임을 암호학적으로 증명하는 최후의 보루 역할을 수행합니다. 이것이 바로 우리가 피싱 사이트의 위협 속에서도 HTTPS를 신뢰할 수 있는 근본적인 이유입니다.

추가적으로, DNS 자체의 보안을 강화하기 위한 기술인 **DNSSEC(DNS Security Extensions)**나, DNS 쿼리 자체를 암호화하는 DoH(DNS over HTTPS), DoT(DNS over TLS) 같은 기술들도 함께 발전하고 있습니다. 이들은 TLS와 함께 다층적인 보안을 구축하는 데 기여합니다.

궁금한게 테스트용으로 윈도우 서버를 vm으로 띄우거 여기서 인증서를 하나 만들었어. 이건 공인된게 아닌데도 내 로컬컴과 이 vm서버가 tls가 되던데 왜 되는거야?

네, 바로 그 부분이 TLS의 또 다른 중요한 측면을 보여주는 아주 좋은 경험입니다. 로컬 테스트 환경에서 “공인되지 않은 인증서”로도 TLS 통신이 가능한 이유를 정확히 이해하면, TLS의 동작 원리를 더 깊게 파악할 수 있습니다.

결론부터 말씀드리면, TLS 통신 자체는 인증서가 ‘공인’되었는지 여부와 상관없이 성립될 수 있기 때문입니다.

TLS 통신이 성공적으로 이루어지기 위한 기술적인 핵심 요건은 다음과 같습니다.

  1. 서버의 공개키(Public Key) 전달: 서버가 클라이언트에게 자신의 공개키가 포함된 인증서를 전달할 수 있어야 합니다.
  2. 암호화 키 교환: 클라이언트와 서버가 그 공개키를 기반으로, 앞으로 통신에 사용할 대칭키(세션 키)를 안전하게 교환할 수 있어야 합니다.
  3. 암호화 통신: 교환된 세션 키를 사용하여 데이터를 암호화하고 복호화하며 통신할 수 있어야 합니다.

사용자님께서 VM의 Windows Server에서 생성한 인증서(자체 서명 인증서, Self-signed Certificate)는 위의 1, 2, 3번 요건을 모두 충족합니다. 즉, 암호화를 위한 기술적인 기능은 완벽하게 수행합니다.

그렇다면 “공인 인증서”와 무엇이 다른가?

차이점은 바로 ‘신뢰(Trust)’ 문제입니다. 기술적인 암호화 기능은 동일하지만, **‘신뢰의 주체’**가 다릅니다.

사용자님의 테스트 상황을 단계별로 분석해 보겠습니다.

1. VM 서버에서 자체 서명 인증서 생성

  • Windows Server (IIS 등)에서 “인증서 생성” 기능을 사용하면, 서버 스스로가 ‘인증 기관(CA)’ 역할을 하여 인증서를 발급합니다.
  • 이 인증서에는 “이 서버의 이름은 my-vm-server.local이고, 소유자는 이 서버 자신이다. 내가 보증한다!” 라고 쓰여 있습니다.
  • 기술적으로는 공개키/개인키 쌍이 정상적으로 생성되고, 인증서 형식(X.509)도 표준에 맞게 만들어집니다.

2. 로컬 PC의 브라우저로 VM 서버에 접속 (https://<VM의 IP 주소> 또는 https://my-vm-server.local)

  • TLS Handshake 시작: 로컬 PC의 브라우저가 VM 서버에 접속하여 인증서를 요청합니다.
  • 서버 응답: VM 서버가 자신이 직접 만든 ‘자체 서명 인증서’를 브라우저에 전달합니다.
  • 브라우저의 검증 (이 부분이 핵심입니다!)
    1. 암호화 기능 검증: “음, 인증서 형식은 올바르고, 공개키도 들어있네. 이걸로 암호화 통신을 시작하는 건 기술적으로 가능하겠어.” (➡️ TLS 통신 자체는 가능!)
    2. 신뢰(Trust) 검증: “그런데 이 인증서를 발급한 기관(Issuer)을 보니 ‘my-vm-server’ 자기 자신이네? Let’s Encrypt, DigiCert, Sectigo처럼 내(브라우저)가 원래부터 믿기로 약속된 ‘신뢰할 수 있는 루트 인증 기관 목록’에 없는 듣도 보도 못한 곳이야. 나는 이 인증서를 신뢰할 수 없어!“

3. 브라우저의 반응: “경고” 후 사용자의 선택

이 “신뢰할 수 없다”는 판단 때문에, 브라우저는 사용자에게 빨간색 경고 페이지를 보여줍니다.

“연결이 비공개로 설정되어 있지 않습니다 (Your connection is not private)” “NET::ERR_CERT_AUTHORITY_INVALID”

이 경고의 의미는 “암호화는 할 수 있지만, 네가 접속한 이 서버가 정말 네가 생각하는 그 서버가 맞는지 나는 보증할 수 없다” 입니다.

그리고 대부분의 브라우저는 이 경고 페이지에서 “고급” 버튼을 누르면 “(안전하지 않음)으로 계속 이동” 이라는 링크를 제공합니다.

4. 사용자가 “계속 이동”을 클릭했을 때

  • 사용자의 명시적인 신뢰 부여: 사용자가 이 링크를 클릭하는 행위는 브라우저에게 다음과 같은 명령을 내리는 것과 같습니다.

    “응, 알아. 이 인증서가 공인되지 않아서 신뢰할 수 없다는 거. 하지만 이건 내 테스트 환경이고, 나는 이 서버를 믿으니까 이번 한 번만 예외적으로 신뢰하고 그냥 통신을 계속 진행해 줘.”

  • TLS 통신 성공: 브라우저는 사용자의 지시에 따라 신뢰 검증 단계를 무시하고, 기술적으로 가능한 암호화 통신 채널을 수립합니다.
  • 결과: 주소창에 “주의 요함” 또는 빨간색 자물쇠 아이콘이 표시된 채로 HTTPS 통신이 이루어집니다. 데이터는 분명히 암호화되어 전송되지만, 브라우저는 “이 연결의 신원은 보증할 수 없다”는 사실을 계속 사용자에게 알려주는 것입니다.

결론

사용자님의 로컬 환경에서 TLS 통신이 성공한 이유는 다음과 같습니다.

  1. 기술적 가능성: 자체 서명 인증서도 암호화 통신을 수행하는 데 필요한 기술적 요건(공개키 전달, 키 교환)을 모두 갖추고 있습니다.
  2. 사용자의 명시적 허용: 브라우저가 “신뢰할 수 없는 인증서”라는 경고를 띄웠을 때, 사용자께서 “위험을 감수하고 계속 진행”을 선택하여 수동으로 신뢰를 부여했기 때문입니다.

이 경험은 TLS가 ① 암호화와 **② 신원 인증(신뢰)**이라는 두 가지 큰 축으로 이루어져 있으며, 개발 환경에서는 ②를 잠시 무시하고 ①의 기능만 테스트할 수 있다는 것을 명확하게 보여주는 아주 좋은 사례입니다. 만약 공인되지 않은 인증서를 사용하는 실제 서비스가 있다면, 모든 사용자가 이 무서운 경고창을 보게 될 것이므로 아무도 그 서비스를 이용하지 않겠죠.

Graph View