안녕하세요,
때때로 포럼에서 혼합 콘텐츠(mixed content) 경고가 나타납니다. 지금 Letsencrypt 커뮤니티를 확인해 보세요:
일부 파비콘 - http://alohadentalgroup.com/assets/icons/favicon.ico
https://sjc4.discourse-cdn.com/letsencrypt/assets/_application-b690f7341f116f756f6621f3fbcc8e6ae69695c2db2f5ebceb6c46aaed19b17f.js 76678:17에서 발견되었습니다.
이 링크들을 https로 변경하거나, 이러한 http 링크를 무시하는 것이 불가능합니까?
혼합 콘텐츠가 있는 포럼은 좋지 않습니다.
해당 favicon URL이 Discourse에 호스팅되어 있지 않은데, Discourse를 사용 중이신가요? 설치 URL이 무엇인가요?
force_https가 활성화되어 있나요?
활성화되어 있다면 아이콘을 다시 업로드해 주세요. 그렇지 않다면 활성화한 후 다시 업로드해 주세요.
잘 모르겠습니다. 저는 Letsencrypt 포럼의 관리자가 아니거든요.
하지만 로컬 옵션이 있다면 내부 Regular 포럼에서 질문해 보겠습니다.
PS: 이동해 주셔서 감사합니다.
경고 메시지는 걱정하지 않으셔도 됩니다.
Let’s Encrypt 사이트의 한 사용자가 이 주제에서 http URL을 추가했습니다: Issues running certbot command - Help - Let's Encrypt Community Support.
이 때문에 브라우저가 혼합 콘텐츠(mixed content)가 있다고(정당하게) 경고합니다.
혼합 콘텐츠 경고는 항상 나쁜 것입니다. http를 통해 쿠키를 추가하여 다음 https 연결에서 사용할 수 있습니다. 따라서 포럼 소프트웨어는 http 연결을 시작해서는 안 됩니다.
특히 “인증서가 잘못되었습니다” 또는 “콘텐츠 경고가 있습니다”(인증서는 정확하지만 혼합 콘텐츠가 있는 경우 - 해당 도메인의 첫 번째 인증서, 링크를 업데이트해야 함)에 대해 논의하는 포럼에서는 더욱 그렇습니다.
해당 favicon은 HTTPS를 통해 사용할 수 없습니다. 혼합 콘텐츠 경고는 이상적이지 않지만, 사용자가 링크가 작동하지 않는 이유에 대해 혼란을 겪는 것보다는 나을 것입니다.
알고 있습니다. 하지만 중간자 공격(MITM)이 브라우저가 시작한 이러한 HTTP 연결을 이용해 HTTP를 통해 쿠키를 추가할 수 있습니다. 이후 브라우저가 해당 쿠키를 HTTPS를 통해 전송하면, 중간자 공격자는 세션 쿠키를 알게 됩니다.
이 방식은 작동합니다. HTTP 상태 코드(404, 301, 410, 500)는 중요하지 않습니다.
이것은
이라는 문제에 해당하지 않습니다. favicon은 사용자가 직접 시작한 링크가 아니며, 사용자는 HTTPS 없이 해당 사이트의 HTTP 링크만 추가하기 때문입니다.
단순한 해결책: 대상이 HTTP인 경우 미리보기를 표시하지 않는 것입니다. 그러면 favicon을 로드할 필요가 없습니다.
서드파티 연결에서는 그렇지 않습니다. 브라우저는 포럼 사이트의 쿠키를 HTTP든 HTTPS든 다른 사이트로 전송하지 않습니다.
존재하지 않는 문제를 만들고 있습니다. 이것이 정말 문제라고 생각하신다면 try.discourse.org에서 이를 입증할 수 있는 익스플로이트를 시연해 주세요.
그것이 문제가 아닙니다. 그렇다면 브라우저 버그가 될 것입니다.
MitM(중간자 공격)은 http://alohadentalgroup.com 연결에서 도메인 alohadentalgroup.com과 해당 도메인의 알려진 세션 쿠키 이름(존재한다면, 확인은 하지 않았습니다. 포럼 도메인의 쿠키가 아닙니다)을 가진 쿠키를 추가할 수 있습니다.
사용자가 나중에 https://alohadentalgroup.com의 로그인을 사용하여 해당 도메인을 관리할 경우, (HTTP를 통해 생성된) 그 쿠키가 HTTPS를 통해 다시 전송됩니다.
이것은 쿠키의 한 가지 중요하고(자주 알려지지 않은) 특징입니다.
이것이 Prefix 쿠키가 생성되는 이유 중 하나입니다. __Secure- 또는 __Host-로 시작하는 쿠키의 경우 HTTPS가 필요합니다. 그러면 더 이상 이것이 불가능해집니다. Preload도 마찬가지입니다(하지만 대부분의 사이트는 HSTS를 사용하지 않고 프리로드되지도 않습니다).
참고(2017)
또는 다른 링크를 확인하세요.
PS: 제 “웹사이트 확인”(프로필 참조)에는 몇 가지 샘플과 작은 데모가 있는 페이지가 있습니다. HTTP를 통해 생성되고 HTTPS를 통해 다시 전송되는 쿠키입니다. HTTP를 통해 __Host- 쿠키를 생성하는 것은 불가능합니다(최신 브라우저 기준). 하지만 Prefix 쿠키는 드뭅니다.