웹 브라우저는 SSL 인증서를 캐시합니까?


26

웹 브라우저가 SSL 서버 인증서를 캐시합니까? 예를 들어, 웹 서버에서 SSL 인증서를 변경하면 모든 웹 브라우저가 SSL을 통해 연결할 때 새 인증서를 선택합니까, 아니면 부실 인증서가있을 수 있습니까?

SSL 인증서가 만료되어 웹 서버에서 새 인증서로 교체되는 시나리오를 생각하고 있습니다.


브라우저가 인증서의 날짜를 확인하여 최신 버전을 가져와야하는지 여부를 확인한다고 가정합니다.
soandos

여기에서 imperialviolet.org/2011/05/04/pinning.html "인증서 고정"에 대해 살펴보고 HSTS 이니셔티브에서 whis는 이전 dev.chromium.org/sts
Shadok

1
2019 년 현재 Chrome 75에서 SSL 인증서를 캐싱하고 있습니다.
Fabian Thommen

답변:


10

글쎄, RedGrittyBrick의 대답은 정확하지만 실제로 질문에 대답하지는 않습니다. 문제는 브라우저가 그렇게 해야하는지, 아니면 해야하는지 아닌지에 대한 것이었다 .

내가 들었던 바에 따르면 MSIE와 Chrome은 실제로 캐시 인증서를 수행하며 이전 버전이 유효한 한 새 버전을 얻을 때 대체하지 않습니다. 그들이 왜 그렇게 하는가는 보안을 낮추기 때문에 이해하기 어렵습니다.


현재 받아 들여진 대답은 분명합니다. 그것은 특별히 즉, 표시 없음 , 브라우저는 인증서를 캐시하지 않습니다. 환경이 바뀌면서 Chrome이하는 이유가 잘 설명되어있는 이유는 이러한 이유와 연결하기에 좋습니다. 인증서가 여전히 유효하기 때문에 의미가없는 보안을 "낮추지"않습니다.
Ramhound

3
이전 SHA-1 키를 최신 키로 교체 할 수 없으므로 이전 키가 여전히 유효하기 때문에 Chrome이 새 키를 무시합니다. 모든 것을 올바르게 이해하면 Chrome이 새 키를 무시합니다. 따라서 더 높은 보안 표준으로 전환하는 방법은 없습니다. 따라서 더 높은 수준으로 푸시 할 수 없어 상대적으로 "낮게"됩니다. 인플레이션이 돈으로 지정된 가치를 낮추지 않고 실제 시장 가치를 낮추는 것처럼.
tuexss

5
+1 StartSSL 혼합 SHA1 / SHA2 체인 오류 이후, Windows의 Chrome이 실제로 중간 인증서를 캐싱하고 있음을 분명히 알 수 있습니다. Chrome은 서버가 보낸 새로운 중간 인증서를 무시합니다. 캐싱이 서버 인증서의 ID 또는 중간 인증서의 ID에 의해 키 지정되는지 여부와 그 ID를 정확히 구성하는 요소는 확실하지 않습니다.
Robert Važan

3
크롬과 파이어 폭스는 모두 일반 창 (이전 인증서)과 시크릿 모드 (올바른 인증서)에서 다른 인증서를 보여줍니다. curl 또는 openssl과 같은 명령 줄 유틸리티는 올바른 인증서를보고합니다. 브라우저의 캐시 (ctrl + shift + del)-크롬의 경우 "쿠키 및 기타 사이트 데이터"및 파이어 폭스의 경우 "오프라인 웹 사이트 데이터"를 지우면 해결되었습니다.
anilech

1
OSX에있는 Firefox (66.0)의 최신 버전은 캐시를 강력하게 유지하는 것 같습니다. 어제 웹 사이트에 대한 TLS 인증서를 업데이트했으며 CLI openssl와 Chromium에 새 인증서가 표시됩니다. Firefox는 캐시를 비활성화하고 다시로드하더라도 모든 캐시 및 오프라인 데이터를 지우고 브라우저를 다시 시작하더라도 이전 버전을 보여줍니다.
Tad Lispy

20

아니요. IBM SSL 개요를 참조하십시오.

  1. SSL 클라이언트는 SSL 버전과 같은 암호화 정보 및 클라이언트의 우선 순위에 따라 클라이언트가 지원하는 CipherSuites를 나열하는 "client hello"메시지를 보냅니다. 메시지에는 후속 계산에 사용되는 임의의 바이트 문자열도 포함됩니다. SSL 프로토콜은 "client hello"가 클라이언트가 지원하는 데이터 압축 방법을 포함하도록 허용하지만 현재 SSL 구현에는 일반적으로이 조항이 포함되지 않습니다.

  2. SSL 서버는 SSL 클라이언트가 제공 한 목록, 세션 ID 및 다른 임의의 바이트 문자열에서 서버가 선택한 CipherSuite를 포함하는 "server hello"메시지로 응답합니다. SSL 서버는 또한 디지털 인증서를 보냅니다 . 서버에 클라이언트 인증을 위해 디지털 인증서가 필요한 경우 서버는 지원되는 인증서 유형 및 허용 가능한 인증 기관 (CA)의 고유 이름 목록이 포함 된 "클라이언트 인증서 요청"을 보냅니다.

  3. SSL 클라이언트는 SSL 서버의 디지털 인증서에서 디지털 서명을 확인하고 서버가 선택한 CipherSuite가 적합한 지 확인합니다.

Microsoft의 요약 도 비슷합니다. TLS 핸드 셰이크도 이와 관련하여 유사합니다.

2 단계에서 클라이언트가 "서버 인증서 전송을 방해하지 말고 캐시를 사용하겠습니다"라고 말하는 방법이 없습니다.

여러 유형의 인증서, 클라이언트, 서버 및 CA가 있습니다. 이들 중 일부는 캐시됩니다.


서버 인증서임을 명확히하기 위해 원래의 질문을 수정했습니다.
Lorin Hochstein

이것은 사실이 아니며 SSL이 작동하는 방식에 대한 개요로 인해 캐시가 없다고 가정하면 캐싱을 제외하는 것은 꽤 나쁜 정당화입니다. youtube.com/watch?v=wMFPe-DwULM
Evan Carroll

사용할 수있는 유일한 캐시는 유효성 검사를위한 것이지만 보안 상충 관계입니다.
다니엘 B

0

입력 내용이 어떤 식 으로든 도움이 될지 확실하지 않지만 방금 경험 한 것이 있습니다. 내 도메인 이름에 SSL 바인딩을 구성하기 전에 크롬에서 https로 액세스하려고했습니다. Chrome은 사이트가 완벽하게 이해되지 않는 사이트 (ERR_CERT_COMMON_NAME_INVALID)가 아니라고 말했지만 인증서를 업로드하고 푸른 색으로 SSL 바인딩을 구성한 후에도 여전히 동일한 오류가 발생했습니다. 이 단계에서 새 개인 브라우저 창을 열거 나 다른 브라우저를 사용할 때 https가 제대로 작동했습니다.

그러나 열린 Chrome 세션에서 작동하지 않을 수 없었습니다. 동일한 SSL 상태를 시도했습니다. 크롬을 완전히 다시 시작한 후에 작동했습니다.

아마도 무언가에 속았을 수도 있지만 인증서가 캐시 된 것처럼 보였습니다 ...


이 오류는 CN에있는 것과 다른 URI로 사이트에 액세스했음을 의미합니다. 바인딩을 설정 한 후 실제로 크롬으로 사이트에 액세스하도록 URI를 변경 했습니까?
세스

아니, 당시에 내가 바꿨 던 것은 구속력뿐이었습니다. 처음 https를 쿼리했을 때 기본 Azure SSL 인증서를 사용하여 제공되었지만 Azure에서 올바른 인증서로 바인딩을 변경 한 후에도 여전히이 서비스를 제공했습니다.
Etienne

도메인 SSL 바인딩을 구성했다고 말 했으므로 시작에서 도메인을 사용하여 서버에 액세스 했습니까? 이 오류는 사용한 URL과 인증서의 URL간에 차이가 있음을 나타냅니다. 그게 내 뜻이야 또한 HSTS 등을 생각하면 실제 서버 구성이 상당히 중요 할 수 있습니다.
Seth

1
1 단계 : 웹 사이트를 Azure에 게시했습니다. 이 단계에는 기본 Azure URL과 기본 인증서가 모두 있습니다. 2 단계 : 웹앱에 대한 사용자 정의 도메인 설정, 이제 mysite.com이 사이트를 올바르게 가리 킵니다. mysite.com의 SSL 인증서는이 단계에서 구성되지 않습니다. 3 단계 :이 시점에서 사이트를 https하려고 할 때 인증서가 일치하지 않는다는 보안 오류가 발생합니다 (그리고 완벽하게 이해됩니다) 4 단계 : Mysite.com의 SSL 인증서를 푸른 색과 여전히 Chrome에서 보안 경고가 나타납니다. 다른 브라우저에서 또는 개인 탐색 메뉴를 열면 발생하지 않습니다.
Etienne

1
5 단계 : Chrome을 다시 시작하면 웹 사이트가 올바른 SSL 인증서를 사용하여 제공됩니다. 따라서 제 결론은 실제로 인증서의 캐싱 문제가 있었다는 것입니다
Etienne

-1

일부 브라우저 개발자 는 2011 년 Diginotar 에 대한 공격과 같은 공격을 탐지하기 위해 이러한 쉐칭 시스템을 구현할 계획입니다 .

그러나 현재 AFAIK에는 현재 브라우저에서 이러한 시스템이 활성화되어 있지 않습니다. 따라서 서버 인증서를 업데이트 할 때이 상황에 대해 생각할 필요가 없습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.