▲

Let's Encrypt, IP 주소 인증서 발급 준비 중

 (community.letsencrypt.org)
6P by GN⁺ 23시간전 | ★ favorite | 댓글 1개
  • Let's Encrypt가 곧 IP 주소 SAN을 포함한 인증서 발급을 지원할 예정으로, 초기에는 6일 만료의 단기(shortlived) 프로필에 한해 제공되고, 일정 기간은 화이트리스트 방식으로 제한 운영됨
  • 정식 공개 전까지는 구체적 일정이나 신청 안내 없이 내부 테스트와 준비가 진행 중
  • 스테이징 환경에서 IPv6 주소가 포함된 샘플 인증서와 이를 적용한 사이트가 공개되었으며, 커뮤니티에 이상 사항이나 피드백 공유 요청
  • Firefox에서 IP SAN 표시에 관련된 버그(BZ #1973855)가 발견되어 테스트가 이어지고 있음
  • DNS SAN과 IP SAN을 혼합한 케이스에서 혼동의 여지가 있음을 실제 테스트 예시로 확인, TLD와 IPv6 주소 표기가 유사할 수 있음을 시연

Let's Encrypt, Getting ready to issue IP address certificates

IP 주소 SAN 지원 준비 상황

  • Let's Encrypt는 곧 생산 환경에서 IP 주소 SAN이 포함된 인증서 발급을 지원할 계획임
  • 해당 인증서는 6일 유효기간의 shortlived 프로필에서만 발급되며, 일정 기간은 허용 리스트(allowlist) 방식으로 제한 운영됨
  • 아직 정식 출시 일정 및 허용 리스트 신청 방법은 미정, 내부 준비가 추가로 필요함

테스트 및 샘플 인증서

  • 스테이징 환경에서 IP SAN을 포함한 샘플 인증서와 실제 적용 사이트(IPv6 주소) 예시가 공개됨
  • 커뮤니티 사용자들에게 이상 사항이나 흥미로운 점, 문제점 발견 시 공유 요청

IP SAN과 DNS SAN 혼합 사례

  • 테스트 과정에서 DNS SAN과 IP SAN이 동시에 포함된 인증서 발급 가능성 및 표기 혼동 사례 시연
  • .cafe 등 특정 TLD와 IPv6 주소 표기가 유사할 수 있어 혼동의 여지가 있음
  • Firefox에서 IP 주소 SAN 표시 관련 버그(BZ #1973855) 도 확인됨

요약

  • Let's Encrypt의 IP 주소 인증서 지원은 화이트리스트 및 단기 인증서로 제한적으로 먼저 적용
  • 실제 서비스 적용 전까지 다양한 케이스 테스트와 커뮤니티 피드백을 통해 안정성·호환성 점검 예정
  • DNS 이름과 IP 주소의 SAN 혼용에 따른 브라우저 표시 이슈 등도 함께 논의되고 있음
▲
GN⁺ 23시간전  [-]
Hacker News 의견

  • IP 주소용 인증서도 유용하다고 생각함
    하지만 Let‘s Encrypt가 S/MIME 인증서를 지원한다면 훨씬 더 큰 영향을 줄 수 있다고 생각함
    수년 전부터 이메일 암호화 관련해서 코믹한 상황이 발생 중임
    이제 대부분의 주요 이메일 클라이언트에서 S/MIME 암호화를 바로 지원하지만, 웹과 마찬가지로 부드러운 사용자 경험을 위해서는 CA에서 인증서를 받아야 함
    신뢰할 수 있고 무료이며 1년 이상 유효한 S/MIME 인증서를 제공하는 CA는 이제 모두 사라짐
    결과적으로 개인 사용자는 이메일 암호화를 전혀 사용하지 않는 상황
    PGP는 너무 불편해서 기술 매니아 외에 거의 사용하지 않음
    이제 우리 이메일도 암호화해야 한다고 생각함
    참고로, CA가 비밀키를 대신 생성해 주면 그 인증서는 신뢰할 수 없다고 봄
    또 S/MIME은 예전 메일 복호화를 위해 예전 인증서를 계속 보관해야 하므로, 자주 바뀌는 인증서는 비실용적임

    • S/MIME에서 예전 메일을 복호화하려면 구 인증서가 필요하다는 이야기에 대해, 복호화 키 자체는 새 인증서도 기존 키를 써서 만들 수 있기 때문에(예: certbot의 --reuse-key 옵션) 꼭 자주 바꾸지 않아도 된다고 봄
      다만 이 방식이 좋은 방법인지는 별개의 문제
      진짜로 필요한 것은 ACME 스타일의 자동 인증서 발급 자동화라고 생각
      지금은 인증서 갱신 과정이 불편해서 거의 사용하지 않음

    • PGP는 이제 WKD(Web Key Directory)링크라는 방식이 있어서 이메일에 TLS의 신뢰망을 적용할 수 있음
      TLS 인증서는 S/MIME 인증서보다 훨씬 받기 쉬운 상황
      신원관리를 제3자가 담당하는 것도 도움이 될 수 있지만, 대부분의 사람들은 그런 신원관리가 잘 맞지 않는 회사에서 일하는 경우가 많음
      만약 회사라면 신원관리를 사내에서 시행하는 것이 더 적합하다고 생각
      최근 있었던 Signalgate 1.0 해프닝링크는 종단 간 암호화의 신원관리 실패라는 점에서 참 배울 것이 많았다고 봄
      이런 점이 S/MIME 인증서나 WKD가 실제로 쓸만한 시스템으로 도입된다면 정부에서도 유용할 수 있겠다는 생각

    • 개인적으로 S/MIME 기반 이메일 암호화에 대한 전망을 좋게는 보지만, 실현 가능성은 낮다고 느낌
      일반 사용자는 비공개키 관리조차 어려워하는 경우가 많고, 이메일 비밀번호조차도 제대로 관리하기 힘들어하는 게 현실
      결국 각 도메인별로 중앙에서 인증서 발급이 필요하거나, 아니면 사용자가 인증서를 받지 못하는 상황이 발생하는 한편, 사이버 범죄자들이 S/MIME 서명 메일을 보내는 문제가 생김
      앞으로 패스키(passkey) 사용이 일반화되고 세대 교체가 이뤄지면 그때가서 키쌍을 직접 다루도록 하는 게 맞는다고 생각

    • 이메일 암호화는 그냥 사라져야 한다는 의견
      참고: Stop using encrypted email

    • S/MIME 암호화에 대해 잘 모르겠어서 궁금한 점이 있음
      왜 같은 프로토콜로 예전 메일을 복호화해야 하는지 궁금
      개인적으로 인증서는 전송 구간(transport)을 위한 용도라고 생각했고, 실제 저장시에는 서버나 호스트의 보관용 암호화가 따로 있을 테니, 전송시에는 단기 인증서, 저장시에는 원하는 방식 암호화 등으로 나눠 쓰는 것이 논리적인데 뭔가 놓치고 있는 부분이 있는지 궁금

  • 모든 주소 관리 기관(예: ISP, 클라우드 제공업체)도 이 흐름에 동참하는 것인지 궁금
    이들은 IP를 아주 빠르게 순환시키는 경우가 있는데, 6일보다 빠르게 바뀌기도 함
    클라우드 제공자도 IP 분석 전 쿨다운 기간을 두거나 해당 IP에 관련된 인증서를 조회 및 폐기한다면 이해가 가지만, 그렇지 않으면 사용자 책임으로 호스트 헤더를 검증하고, 원하지 않는 IP 기반 연결을 거부하거나, 레거시 인증서가 완전히 없어질 때까지 기다려야 하는 복잡성 발생
    클라우드 제공업체별로 IP 인증서를 얼마나, 얼마에 받을 수 있는지도 궁금함

    • 사실 이런 문제는 클라우드 제공업체의 커스텀/바니티 도메인 제공과 별반 다르지 않다고 생각
      예를 들어 Azure에서는 myapp.westus.cloudapp.azure.com 같은 DNS를 VM에 연결할 수 있는데, CA에서 누구나 저 도메인에 인증서를 발급받을 수 있음 참고
      이런 경우도 별도의 쿨다운 없이 VM이 소멸하면 다른 사람이 바로 그 도메인을 가져갈 수 있음

    • HTTPS 인증서는 도메인 만료 하루 전에 90일짜리로 갱신 가능하고, CA에서는 결제카드 한도도 알 수 없음
      IP 인증서 쓸 사람들은 대부분 금방 IP를 폐기하고 떠나는 사용자와는 다를 것
      가장 유용한 사례는 아주 특이한 레거시 소프트웨어나, Cloudflare 처럼 공유 IP 없이 ECH(Encrypted Client Hello)나 ESNI(Encrypted SNI) 지원이 필요한 경우
      첫 번째 사례(레거시)는 IP를 쉽게 포기하지 않을 테고, 두 번째(ECH/ESNI)는 실제 도메인에 접속이 성사되기 어렵다고 생각

    • ISPs가 동참해야 하느냐는 질문엔 오히려 거꾸로 간다고 봄
      ISPs의 역할이 TLS 표준에 맞는 방식으로 IP를 할당하는 게 아니고, TLS 인증 제공자가 생태계의 신원(도메인, IP 등…) 연결 방식에 맞춰 "신원 검증" 역할을 해야 한다고 생각
      이번에 어떻게 접근할지 자세히 나와 있진 않지만, 내 직감엔 LetsEncrypt가 ASNs(자율 시스템 번호) 기준 장기간 IP 이관이 이뤄지는 리스트를 만들어서(공개 DB처럼 Mozilla Public Suffix List를 공동 유지) 오직 그 리스트 내의 IP에만 인증서를 발급하고, 다른 ASN으로 이전하면 인증서 무효화 관리 등을 할 듯
      다른 ACME 발급기관과도 공유하는 방식을 기대함

    • 다양한 클라우드에서 IP 인증서를 얼마에, 몇 개나 받을 수 있는지 궁금하다면, 향후 와일드카드 인증서 지원이 생길 지도 궁금함

    • 내 상황에선 단 하루만 IP 인증서가 있어도 https URL 테스트를 할 수 있으니 아주 반가운 변화라고 생각

  • 기술적으로는 동작 원리를 알겠는데, 실제 의도된 사용처가 무엇인지 궁금함

    • ECH(Encrypted Client Hello)나 ESNI(Encrypted SNI) 지원만으로도 큰 의미가 있다고 생각
      ESNI 초기에는 Cloudflare 같은 대형 https 프록시만 적용할 수 있어서 IP 인증서 도입이 꿈 같은 아이디어로 여겨졌는데, 이제 모든 서버가 ESNI/ECH에 참여할 수 있음
      클라이언트들이 모든 서버에 IP 인증서가 있다고 가정하고 ESNI를 시도하기 시작하면, 인터넷 전역 프라이버시 향상에 큰 도움이 될 것으로 기대함

    • 여러 답변에서 좋은 사례가 나왔지만, NTS(Network Time Security)도 언급할 만함
      IP 인증서를 못 받으면 NTS에도 DNS가 필요해서, DNS가 다운되면 인증된 시간 동기화가 아예 불가능해짐
      DNSSEC는 올바른 시각 없으면 검증에 실패하는데, DNS+NTS 의존이면 복구 불가
      IP가 포함된 인증서로 DNS 필요 없이 인증된 시각 배포가 가능하면 이런 문제를 해결할 수 있음

    • DNS가 상당히 바뀌는 과정에서도 유효한 인증서를 유지해야 할 경우, 예를 들어 대시보드 접근성 확보라든지, 예전 자동화가 DNS 오류로 멈추지 않게 하기 위해서 쓸 수 있음
      다른 사례로는 DNS 필요 없이, 더욱 단순하게 테스트 환경을 바로 구축하거나 Cockpit 등 외부 노출을 빠르게 하는 경우도 생각 가능
      사실상 상상력이 허락하는 다양한 활용처가 생김

    • authdns(인증 DNS 서버) 대상으로 '기회주의적(opportunistic)' DoTLS(TLS 기반 DNS 쿼리)를 할 때도 흥미로운 방식이 될 수 있음
      공개 IP를 SAN(Subject Alternative Name)으로 포함하는 인증서로 인증 DNS 서버가 DoTLS 포트에서 서비스할 수 있음
      지금도 호스트네임으로 가능하지만 하나의 퍼블릭 IP에 여러 다양한 네임이 있을 수 있어서, IP 기반 SAN이 더 명확히 묶어주게 됨

    • 호스트네임 대신 프로젝트에 바로 IP 연결하는 등 취미나 일회성 목적으로 도메인 없이 쓰기를 원하는 사람들에게 적합하다고 생각

  • 왜 인터넷 지역 등록기관(RIR)이나 로컬 등록기관(LIR)에서 인증서를 발급하지 않는지 궁금
    왜 제3자가 RIR, LIR 등록자를 검증해야 하는지, 도메인 등록자에겐 일이 너무 많다는 건가
    이유가 똑같은지 의문

  • TLS를 새롭게 악용할 수 있는 구멍이 늘어난 것 같다는 생각
    이전까지는 소유하지 않은 도메인에 대한 인증서를 발급한다는 이슈였는데, 이제는 소유하지 않은 IP에 대한 인증서가 가능할 수도 있음
    블랙햇 해커들이 텔레그램에서 신나게 떠들 듯

    • 사실 IP 인증서는 예전부터 존재했고, 바뀐 점은 이제 Let's Encrypt에서도 제공한다는 것뿐임

  • 이로 인해 로컬 라우터(예: 192.168.0.1) 관리 페이지에 self-signed 오류 없이 https 접속이 가능한지 궁금함

    • 불가능하지만, 가능해질지도 모름
      로컬 주소는 범용적으로 할당하는 게 아니고, 글로벌 라우팅도 안 되기 때문에 본질적으로 검증할 방법이 없음
      하지만 라우터 제조사가 의지가 있다면, CG-NAT 뒤에 있지 않고 퍼블릭 IPv4 주소가 할당된 장비에서라면, 퍼블릭 주소로 인증서를 요청하는 것은 가능함
      IPv6는 대부분 글로벌 라우팅이 되니 더욱 쉽다고 봄

    • 불가능하고, 그렇게 되어서도 안 됨
      실제로는 프록시와 실제 도메인, 진짜 인증서를 이용하고 DNS 리라이트 기능을 조합하면 충분히 가능
      예를 들어 nginx manager UI와 adguard를 DNS로 사용
      라우터의 DNS를 adguard로 한정, 내 도메인은 proxy로 리라이트
      도메인을 등록하고 진짜 인증서 발급받으면 해결
      나도 모든 로컬 서비스를 https로 쓰고 있음

    • 사설 IP에는 인증서가 발급되지 않음
      동일한 사설 IP가 다른 네트워크의 전혀 다른 장비로 매번 바뀔 수 있어, 독점 소유권이 보장되지 않기 때문임

    • 오히려 반대임
      공인 IP가 아닌 경우 유효한 인증서 발급 불가
      이미 도메인 인증서를 받아 해당 도메인을 192.168.0.1로 포워딩하는 방법이 있음

    • 인증서를 받으려면 해당 IP(공인 IP)를 실제로 소유해야 함

  • 내부 IPv4(192.168.x.x, 172.16.x.x, 10.x.x.x)용 인증서도 가능할지, 혹은 브라우저에서 이런 주소를 무시하는 게 맞는지, 만약 그렇지 않으면 내부망용 와일드카드 인증서라도 발급받을 수 있는지 궁금함

    • 공용(public) CA가 발급하는 인증서 맥락에서 위 질문은 의미가 맞지 않는다고 생각
      도메인과 달리 10.10.10.10 같은 사설 IP는 수많은 사람이 동시에 "소유" 중
      내부 개발용이라면 mkcert 같은 툴이 있고, 회사 내부 공유 자원이라면 도메인 기반 TLS 인증서가 더 간편함

    • 만약 장비의 개인키가 절대로 유출되지 않는다는 걸 증명할 수 있다면, 기존 CA로도 시도 가능함
      하지만 내부 주소 인증서 관련해서는 누군가 기기를 사서 개인키를 얻어내면 즉시 인증서 키 폐기가 문제됨
      그래서 신뢰할 수 있는 기기라면 수동으로 인증서를 임포트해서 오류 없이 접속하거나, 여러 기기가 있다면 자체 CA를 구축해서 인증서 배포하는 것이 현실적임
      오픈소스 ACME 서버로 Let's Encrypt와 동일 방식의 발급 자동화가 내부에서도 가능

    • DNS를 퍼블릭 서버로 우선 지정해 인증서 발급받고, 그 후에는 DNS를 내부 192.168… 주소로 내려받아 인증서와 키를 복사하는 방식
      유의할 점은 일부 라우터가 내부 주소로 포워딩되는 DNS 응답을 블랙홀링할 수 있으니 사전 테스트 필요

    • 브라우저가 프라이빗 네트워크를 무시하지 않아야 한다고 봄
      내 경우엔 프라이빗 네트워크란 내 로컬 라우터에 불과하지만, 남들에겐 전세계를 아우르는 망일 수도 있음

  • 예시 인증서에는 subject 필드가 없는 것이 흥미로움
    IP로 요청하고 SAN에 DNS가 기재되어 있어서 그런지 궁금함

    • Let's Encrypt팀에 따르면, 앞으로 subject common name 대신 subject alternative names 방식만 사용할 계획임
      6일짜리 단기 인증서 프로필에서 이미 적용됐고, "클래식" 90일짜리 프로필에는 아직 적용되지 않았다고 함

  • CVE-2010-3170 취약점이 다시 부각될 시점인지 농담 삼아 언급

    • 직접 X.509 검증 로직을 구현한다면 그런 취약점이 남아 있을 수 있지만, 실제로 이걸 노리려면 잘못 동작하는 CA가 해당 인증서를 발급해줘야 하므로 가능성은 낮다고 생각

  • 아쉽게도 IP 주소용 인증서는 DNS 챌린지 방식으로 발급이 불가능
    하지만 왜 그런지 이해는 됨

답변달기