SSL 인증서를 지불해야하는 이유는 무엇입니까?
대부분의 경우 지불해야 할 이유가 없습니다.
예외 요약은 맨 아래를 참조하십시오.
한 걸음 물러서서 인증서의 기능과 대략적인 방법을 설명하겠습니다.
일반적으로 "인증서"라고하는 것은 두 개의 연결된 부분으로 구성됩니다.
- 인증서 적절한 공개 키 (예 : 도메인 이름과 같은) 일부 식별을 포함.
- 개인 키 홀더 (만 홀더) 디지털들은 위의 인증서를 사용하여 검증 할 수있는 방법으로 메시지에 서명 할 수 있습니다.
의 인증서를 원하면 yourdomain.com다음을 수행하십시오.
- 개인 / 공개 키 쌍을 만들고 개인 부분을 안전하게 유지하십시오.
- 질문 에 대한 인증서를 생성하기 위해 신뢰할 수있는 타사 ( "CrediCorp")를
yourdomain.com공개 키.
- 당신이 제어하는 CrediCorp에 어떤 식 으로든 증명하십시오
yourdomain.com.
- 개인 키와 획득 한 인증서를 서버에 넣고 웹 서버가이를 사용하도록 구성하십시오.
그런 다음 Alice가 방문 yourdomain.com하면 브라우저는 개인 키로 서명 된 메시지와 함께 웹 서버에서 인증서를 가져옵니다. 그런 다음 브라우저는 세 가지를 확인합니다.
- 서명 된 메시지는 인증서로 확인할 수 있습니다 (해당 서명이 있어야하는 해당 개인 키로 서명 된 것임
yourdomain.com).
- 인증서의 도메인은 브라우저가 방문하려는 도메인 (
yourdomain.com)입니다.
- 인증서는 CrediCorp의 것입니다.
이 세 가지의 조합은 Alice가 그녀가 실제로 yourdomain.com어떤 사기꾼과 대화하고 있음을 보증 합니다 . Alice가 CrediCorp를 신뢰한다면 .
( 이 진정성을 비밀로 바꾸는 암호 부두 춤 도 있습니다 .)
Alice 는 CrediCorp를 어떻게 신뢰합니까?
이것이 진정한 요점입니다. 요컨대, CrediCorp는 "이봐, 우리는 인증서를 만들 것"이라고 말했다. 많은 규칙에 따라 많은 노력을 기울인 후 , CrediCorp가 실제로 신뢰할 만하고 일부 사람들에게 인증서를 올바르게 발행 할 것임을 설득했습니다.
특히, 그들은 파이어 폭스 (Firefox)를 제작자들에게 확신시켜주었습니다. 결과적으로 CrediCorp는 Firefox의 A-list를 획득하며 해당 인증서는 기본적으로 Firefox에서 신뢰합니다. 따라서 Alice는 귀하가 제어한다고 주장 할 때 Firefox를 신뢰하고 Firefox는 CrediCorp를 신뢰하며 CrediCorp는 (확인 후) 신뢰할 수 있습니다 yourdomain.com. 거의 체인 과 같습니다 .
그러나 Firefox는에 대한 인증서를 발급하기 위해 CrediCorp를 신뢰하는 것이 아니라 모든 도메인에 yourdomain.com대한 CrediCorp 인증서를 신뢰 합니다. 또한 Firefox 는 모든 도메인에 대해 ShabbyCorp 를 신뢰합니다.
결과가 발생합니다. 누군가가 ShabbyCorp가 자신이 제어하고 있다고 ShabbyCorp에게 설득 할 수 있다면 yourdomain.com(ShabbyCorp가 철저하지 않기 때문에), yourdomain.com해당 개인 키로 ShabbyCorp 인증서를 얻을 수 있습니다 . 그리고이 인증서를 사용하면 웹 서버를 가장 할 수 있습니다. 결국, 그들은 yourdomain.com파이어 폭스가 신뢰 하는 인증서 (플러스 키)를 가지고 있습니다!
CrediCorp와 ShabbyCorp는 간단히 CA ( Certificate Authorities ) 라고 합니다. 실제로 ComodoSSL과 Let 's Encrypt는 CA의 예입니다. 그러나 더 많은 것들이 있습니다. 이 글을 쓰는 시점에서 Firefox는 154 개의 CA를 신뢰합니다 .
우와 그러나 그것은 어떻게 내 질문에 대답합니까?
나는, 흠 ...
여기 있습니다. 위에서 설명한 메커니즘은 모든 인증서에 적용됩니다. 웹 사이트에 대해 올바른 신뢰할 수있는 인증서가 있으면 작동합니다. 브랜드 A 인증서와 브랜드 B 인증서에는 특별한 것이 없습니다. 그들은 모두 동일한 CA 요구 사항과 동일한 암호 수학의 적용을받습니다.
CrediCorp를 더 좋아하는 경우에도 훨씬 신뢰할 수있는 것처럼 들리지만 실제로 사용하면 도움이되지 않습니다. 공격자가 ShabbyCorp가 사이트에 대한 인증서를 제공하도록 설득 할 수있는 경우 공격자는 사용자의 위치에 관계없이 해당 인증서를 사용하여 사이트를 가장 할 수 있습니다.
Firefox가 ShabbyCorp를 신뢰하는 한 방문자는 차이를 볼 수 없습니다. (예, 방문자는 인증서를 가져 와서 인증서를 발굴하여 누가 발급했는지 확인할 수 있습니다. 그러나 누가 그렇게합니까?) 인증서를 위조하는 것과 관련하여 전체 시스템은 150 개 이상의 CA 중 가장 약한 것입니다. 예, 그 이유는 무엇 이며 무서운, 그리고 그것의 아마 가장 큰 비판 사람들이 전체 계획의 있습니다. 아직도, 우리가 붙어있는 것입니다.
중요한 것은 "좋은"인증서를 제공하는 CA를 신뢰하지 않으면 다른 곳에서 인증서를 얻는 것이 큰 도움이되지 않는다는 것입니다.
모든 것이 똑같이 운명입니다. 경고가 없습니까?
Weeeelllll ...
마지막 섹션에서 만든 요점을 없애는 것으로 시작하겠습니다. 요즘에는 DNS-CAA를 사용 하여 선택한 CA에만 도메인 을 잠글 수 있습니다 . Comodo를 신뢰하고 다른 CA를 신뢰하지 않는다고 가정하면 Comodo 이외의 모든 CA에 도메인에 대한 인증서를 발급하지 않도록 요청할 수 있습니다. 이론에 의하면. (브라우저는 DNS-CAA를 검사하지 않기 때문에 CA를 발급해야합니다. 따라서 손상된 CA는이 보호 기능을 무시할 수 있습니다.)
그 문제를 기꺼이 겪고 싶다면 문제는 다음과 같습니다. 암호화하자. 아니면 덜 안전합니까? 신뢰성은 어려운 문제입니다. 어떻게 수량화합니까? 내가 말할 수는 없다는 것이다 나의 인식에 하자 암호화는 다른 CA를보다 신뢰할 수 있습니다. 유효성 검사의 보안에 관해서는 상용 CA가 수행하는 것과 매우 유사합니다 (DV 인증서의 경우). 이 질문 도 참조하십시오 .
가치있는 점 :이 사이트의 일부인 StackExchange 네트워크는 현재 Let 's Encrypt 인증서를 사용합니다. 대부분의 사람들은 이것을 눈치 채지 못할 것이며, 만일 그들이 그렇게한다면 그것이 그들에게 많은 의미가 있는지 진심으로 의심합니다.
인증서가 의미가 있으려면 소프트웨어 공급 업체 가 발급하는 CA를 신뢰 해야합니다 . 그렇지 않으면 인증서가 쓸모가 없습니다. 필자는 Firefox를 예로 사용했지만 실제로 Firefox, Chrome, Windows, Mac OS X, iOS 및 Android의 최신 버전과 다소 오래된 버전에서 CA를 신뢰하기를 원합니다. 그리고 수십 명의 작은 선수들. 고려해야 할 CA (ComodoSSL 및 Let 's Encrypt 포함)는 이러한 모든 엔터티에서 신뢰합니다.
CA가 오작동하거나 신뢰할 수없는 것으로 밝혀 지면 인증서 소유자의 날을 망칠 정도로 다양한 신뢰 저장소에서 신속하게 제거됩니다 . 내가 아는 주목할만한 두 가지 예는 DigiNotar 와 StartCom / WoSign입니다 (기사를 확인하면 신뢰 역학에 대한 흥미로운 통찰력을 제공합니다!). 따라서 Let 's Encrypt가 엉망이되거나 다른 이유로 떨어질 것이라고 생각한다면, 사용하지 않으면 특정 낙진에 빠지지 않을 것입니다.
인증서는 일부 암호화 수학 마술을 사용합니다 . 문제는 어떤 암호 수학 마술 입니까? 약한 마법이라면? 이것은 실제로 중요한 문제이며 CA는 이것을 업그레이드 할 때도 발을 끌고 있습니다. 운 좋게도 브라우저 공급 업체는 인증서 승인을 위해 여기에 최소값을 설정하여 여유를 얻었습니다. 예를 들어, RSA-1024 또는 SHA-1을 사용하는 인증서 는 이제 대부분의 브라우저에서 거부되므로 실제로 작동하는 인증서는 더 이상 사용되지 않는 암호화 기본 형식을 사용하지 않습니다. 결론은 모든 CA (암호화 포함)가 더 이상 이 부분 을 실망시키기가 어렵다는 것입니다.
이전에는 모든 인증서가 동일하게 생성되었다고 말했습니다. 나는 거짓말하지 않았다. 특히, 지금까지 논의한 내용은 " DV ( Domain Validated ) 인증서"로, 대부분의 웹 사이트에서 사용됩니다. 브라우저가 URL 표시 줄에 표시되는 도메인과 실제로 통신하고 있는지 확실하게 측정합니다. "Organization Validated (OV)"및 " EV ( Extended Validation )"인증서도 있으므로 CA의보다 정교한 검사가 필요합니다. 특히, 당신은 단지에 대한 EV 인증서를 얻을 수 있어야합니다 somebank.com당신은 실제로 당신이 증명할 수 있다면, / SomeBank 사 입니다 SomeBank, 주식 회사
EV 인증서는 비용이 많이 듭니다 (볼 파크 : 연간 수백 유로 / USD). 브라우저에 녹색 URL 표시 줄 또는 자물쇠가 표시 될 수 있으며 "SomeBank, Inc."가 표시 될 수 있습니다. 게다가. DV 인증서와 달리 웹 사이트의 실제 소유자에 대한 아이디어도 제공합니다. 거꾸로, 그들은 더 합법적으로 보일 수 있습니다. 실망스러운 점은 사용자가 거의주의를 기울이지 않기 때문에 효율성이 제한적입니다.
위조 된 DV 인증서가있는 공격자는 EV 인증서가 제공 할 수있는 추가적인 시각적 단서가 없어도 사이트를 가장 할 수 있으며 사용자는 일반적으로 그 차이를 알지 못합니다. 반대로 피싱을 쉽게하기 위해 오해의 소지가있는 EV 인증서 를 얻을 수 있습니다. 결과적으로 크롬 과 파이어 폭스 는 시각적 인 끄덕임을 EV 인증서에 버리고 일부 사람들은 완전히 사라질 것이라고 생각 합니다.
은행이라면 지금 당장 EV 인증서를 원할 것입니다. 그렇지 않으면 그렇게 많지 않습니다. 그러나 EV 가 필요한 경우 Let 's Encrypt는 단순히 EV 인증서를 제공하지 않기 때문에 적합하지 않습니다.
인증서는 제한된 시간 동안 만 유효합니다 . 일반적인 상업용 CA의 인증서는 1 년 동안 유효한 경향이 있지만 3 개월에서 3 년까지는 아무것도 보지 못했습니다. 인증서 암호화는 90 일 동안 유효하며 ,이 범위는 짧은 편이므로 자주 갱신해야합니다. Let 's Encrypt 사용자의 경우 일반적으로 60 일마다 인증서가 교체되도록 자동화됩니다.
광범위하게 사용 가능한 소프트웨어를 사용하여 갱신을 자동화 할 수 있다는 것이 실제로 인증서가 만료 된 해보다 쾌적 합니까? CA에서 내 로그인은 무엇입니까? 이것은 어떻게 다시 작동합니까? 대부분의 소규모 사이트는 상업용 CA에서 끝나는 것처럼 보입니다.
전에는 우리 모두가 신뢰할 수있는 CA가 너무 많기 때문에 무섭습니다. 그러나 신뢰 저장소에서 단일 CA를 제거하면 사용자에게 미치는 영향이 제한적이라는 점에서 많은 CA를 보유하는 것도 이점이됩니다. 특히, 단일 CA를 삭제하면 해당 CA에서 발급 한 인증서에만 영향을 미칩니다. 모두가 하나의 단일 CA ( 일부 사람들이 Let 's Encrypt로 발생할 수 있음 )를 사용하게되면 모든 신뢰를 집중하고 해당 조각화의 이점을 잃게됩니다.
마지막으로, 상업적 지원 또는 백만 달러 SSL 보증 과 같은 유료 CA가 제공 할 수있는 다른 이점도 있습니다 . 나는이 두 가지 측면에 대해 거의 믿지 않지만 Let 's Encrypt가 제공하지 않는 것들입니다.
머리가 아파요. 질문이 있습니다.
편안한 느낌을 사용하십시오! DV 인증서의 경우 다양한 CA를 실제로 구별하는 것은 거의 없습니다. 나는 Let 's Encrypt를 직업적으로나 개인적으로 모두 사용하며 행복합니다.
Let 's Encrypt를 피해야 할 이유는 네 가지뿐입니다.
- EV (또는 OV) 인증서가 필요한 경우
- 인증서 갱신을 자동화 할 수 없거나 원하지 않으면 3 개월의 인증서 유효 기간이 너무 짧습니다.
- Let 's Encrypt를 신뢰하지 않는 경우 (DNS-CAA와 같은 다른 방법도 고려해야합니다. 그러면 브라우저에서도 Let 's Encrypt를 블랙리스트에 추가해야합니다).
- Let 's Encrypt가 어떤 이유로 브라우저에서 중단되거나 중단 될 것이라고 생각하는 경우.
해당 사항이 없으면 인증서 비용을 부담하지 마십시오.