HTTP 완전 전송 보안

HTTP Strict Transport Security

HTTP Strict Transport Security(HSTS)는 프로토콜 다운그레이드[1] 공격 및 쿠키 하이잭같은 중간자 공격으로부터 웹 사이트를 보호하는 정책 메커니즘입니다.서버(또는 기타 준거 사용자 에이전트)가 HTTPS 접속만을 사용하여 자동으로 상호 작용해야 선언할 수 있습니다.이 접속은, 시큐어하지 않은HTTP 와는 달리, Transport Layer Security(TLS/SSL)를 제공합니다.HSTS는 IETF 표준 추적 프로토콜로, 에서 지정됩니다. RFC6797.

HSTS 정책은 "라는 이름의 HTTP 응답 헤더필드를 통해 서버에 의해 사용자 에이전트에 전달됩니다.Strict-Transport-Security".[1] HSTS 정책은 사용자 에이전트가 안전한 방법으로만 [2]서버에 액세스해야 하는 기간을 지정합니다.HSTS를 사용하는 웹 사이트에서는 HTTP를 통한 접속을 거부하거나 사용자를 HTTPS로 체계적으로 리다이렉트하여 클리어 텍스트HTTP를 허용하지 않는 경우가 많습니다(단, 이는 사양상 필요하지 않습니다).그 결과 TLS를 실행할 수 없는 사용자 에이전트는 사이트에 접속할 수 없게 됩니다.

보호는 사용자가 사이트를 한 번 이상 방문한 후에만 적용되며, 최초 사용 시 신뢰 원칙에 의존합니다.이 보호는 HTTP를 지정하는 사이트에 대한 URL을 입력하거나 선택하는 사용자가 HTTP 요청을 작성하지 않고 HTTPS로 자동 업그레이드되므로 HTTP man-in-the-middle 공격이 발생하지 않습니다.

사양 이력

HSTS 사양은 2012년 10월 2일 IESG에 의해 표준 [3]RFC 제안으로 발행이 승인된 후 2012년 11월 19일 RFC 6797로 발행되었습니다.저자들은 당초 2010년 6월 17일 인터넷 초안으로서 제출하였다.인터넷 초안으로의 변환에서는, 사양명이 「Strict Transport Security」(STS)에서 「HTTP Strict Transport Security」(HTTP Strict Transport Security)로 변경되었습니다.이것은 사양이 [4]HTTP에만 적용되기 때문입니다.HSTS 사양에 정의되어 있다HTTP 응답 헤더필드는 "Strict-Transport-Security"라는 이름으로 유지됩니다.

당시 명칭이 "STS" 규격의 마지막 "커뮤니티 버전"은 2009년 12월 18일에 공개되었으며,[5] 커뮤니티 피드백을 기반으로 개정되었다.

PayPal, Collin Jackson 및 Adam Barth의 Jeff Hodges에 의한 원본 초안 사양은 2009년 [6]9월 18일에 발행되었습니다.

HSTS 사양은 Jackson과 Barth의 논문 "ForceHTTS: 네트워크 공격으로부터 보안 수준이 높은 웹 사이트 보호"[7]에서 설명한 대로 원본 작업에 기초하고 있습니다.

또한 HSTS는 Jeff Hodges와 Andy Steingruebl이 2010년 논문 The Need for Communicient Web Security Policy Framework([8]s)에서 제시한 웹 보안 개선을 위한 전체적인 비전의 한 측면을 실현하는 것입니다.

HSTS 메커니즘의 개요

서버는 HTTPS 접속을 통한 헤더를 제공함으로써 HSTS 정책을 구현합니다(HTTP를 통한HSTS 헤더는 [1]무시됩니다).예를 들어 서버는 향후 1년간 도메인에 대한 요구(최대 경과시간은 초단위로 지정, 31,536,000은 1개의 비윤리 연도와 동일)가 HTTPS만을 사용하도록 헤더를 송신할 수 있습니다.Strict-Transport-Security: max-age=31536000.

웹 응용 프로그램이 사용자 에이전트에 HSTS 정책을 발행하면 적합 사용자 에이전트는 다음과 같이 동작합니다(RFC 6797).[9]

  1. 웹 응용 프로그램을 참조하는 모든 보안되지 않은 링크를 자동으로 보안 링크로 변환합니다(예:http://example.com/some/page/로 변경된다.https://example.com/some/page/ (서버에 액세스 하기 전에)
  2. 접속의 보안을 확보할 수 없는 경우(서버의 TLS 증명서를 신뢰할 수 없는 경우 등), 사용자 에이전트는 접속을 종료하고(RFC 6797 섹션 8.4, Secure Transport Establishment의 오류), 사용자가 웹 응용 프로그램에 액세스할 수 없도록 해야 합니다(섹션 12.1, No User Resort).

HSTS 정책은 웹 응용 프로그램 사용자를 일부 수동적(eabesdropping)[10]활성 네트워크 공격으로부터 보호합니다.중간자 공격자는 사용자의 브라우저가 해당 웹 응용 프로그램에 대해 HSTS 정책이 유효할 때 사용자와 웹 응용 프로그램 서버 간의 요청 및 응답을 가로채는 기능이 크게 감소합니다.

적용 가능성

HSTS가 해결할 수 있는 가장 중요한 보안 취약성은 SSL 스트라이핑의 man-in-the-middle 공격입니다.Moxie Marlinspike는 2009년 BlackHat Federal talk "New Tricks For Beading SSL In Practice"[11][12]에서 처음 공개했습니다.SSL( TLS) 스트리핑 공격은, 시큐어 HTTPS 접속을 플레인 HTTP 접속으로 투과적으로 변환하는 것으로 동작합니다.사용자는 접속이 안전하지 않음을 알 수 있지만, 중요한 것은 접속이 안전한지 여부를 알 수 있는 방법이 없습니다.Marlinspike의 강연 당시 많은 웹사이트가 TLS/SSL을 사용하지 않았기 때문에 플레인 HTTP의 사용이 공격에 의한 것인지, 아니면 단순히 웹사이트가 TLS/SSL을 실장하지 않았기 때문에 (사전 지식이 없는) 알 수 없었습니다.또한 다운그레이드 프로세스 중에 사용자에게 경고가 표시되지 않아 공격이 공정하게 진행되었습니다.가장 경계심이 강한 사람 외에는 모두에게 미묘하다.Marlinspike의 sslrip 툴은 [citation needed]공격을 완전히 자동화합니다.

HSTS는 사이트에 접속할 때 항상 TLS/SSL을 사용해야 함을 브라우저에 통지함으로써[10] 이 문제에 대처합니다.사용자가 처음 방문하는 경우 공격자가 HSTS 헤더를 제거할 수 있습니다.Google Chrome, Mozilla Firefox, Internet Explorer 및 Microsoft Edge는 HSTS 사이트의 [13][14][15]"사전 로드된" 목록을 포함하여 이 문제를 제한하려고 합니다.유감스럽게도 이 솔루션은 인터넷상의 모든 웹 사이트를 포함하도록 확장할 수 없습니다.아래 제한을 참조하십시오.

HSTS는 Firesheep [16]등 널리 이용 가능한 툴에 의해 쿠키 기반의 웹 사이트 로그인 자격 정보가 도용되는 것을 방지하는 데도 도움이 됩니다.

HSTS는 시간이 제한되어 있기 때문에 피해자의 컴퓨터 시간을 이동하는 공격(: 잘못된 NTP [17]패킷 사용)에 민감합니다.

제한 사항

플레인 HTTP 등의 안전하지 않은 프로토콜을 사용하거나 안전하지 않은 [18]채널을 통해 초기 요청의 URI를 얻은 경우 초기 요청은 활성 공격으로부터 보호되지 않습니다.애드버타이즈된 HSTS 정책에 지정된 액티비티 기간 후 첫 번째 요청에도 동일한 내용이 적용됩니다.max-age(사용자의 액티비티와 동작에 따라 며칠 또는 몇 개월로 설정할 필요가 있습니다).Google Chrome, Mozilla Firefox 및 Internet Explorer/Microsoft Edge는 HSTS를 [19][13][14][15]지원하는 알려진 사이트를 포함하는 목록인 "HST 프리로드 목록"을 구현하여 이 제한을 해결합니다.이 목록은 브라우저와 함께 배포되므로 나열된 사이트에 대한 초기 요청에도 HTTPS를 사용합니다.앞서 설명한 바와 같이 이러한 사전 로드된 목록은 전체 웹을 포함하도록 확장될 수 없습니다.DNS 레코드를 사용하여 HSTS 정책을 선언하고 DNSSEC를 통해 안전하게 액세스하고(옵션으로 증명서 핑거 프린트를 사용하여 유효성을 확인함으로써) 잠재적인 해결책이 실현될 수 있습니다(라스트 마일 [20]문제를 방지하려면 검증 리졸버를 실행해야 합니다).

Junade 알리HSTS꾼 도메인의 사용에 대해서 비효율적이다;에 대한 Man-in-the-Middle 요격 list,[21]이 가능한 DNSSpoofing Attacks,[22]에 의해 또는 오해를 살 정도로 닮은 단순한 도메인 이름을 떨칠 수 있는 HSTS Preload이 아닌 인위적인 도메인에서 교통 봉사하기 위해DNS-based 공격을 이용하여, 그것 가능하다고 지적했다.그 아무도 있습니다.도메인 이름(www.example.org 대신 www.example.org 등)을 지정합니다.

HSTS는 "사전 로드된 목록"을 사용하더라도 Juliano Rizzo 및 Tai Duong에 의해 도입된 BEAST 또는 CRIME 공격 등 TLS 자체에 대한 고도의 공격을 막을 수 없습니다.TLS 자체에 대한 공격은 HSTS 정책 적용과 직교합니다.서버 공격으로부터도 보호할 수 없습니다.누군가가 공격했을 경우, TLS를 개입시켜 어떠한 컨텐츠도 정상적으로 처리됩니다.

HSTS 의 보안에 관한 전체적인 고려사항에 대해서는, RFC 6797 을 참조해 주세요.

프라이버시 문제

HSTS를 사용하면 브라우저의 "incognito" 프라이버시 모드를 유지하거나 "incognito" 프라이버시 모드를 종료할 수 있는 복구 가능한 식별 데이터(슈퍼쿠키)를 사용하여 방문 브라우저에 거의 태그를 붙일 수 있습니다.20 다른 영역에 20브라우저 요청 사용된다 예를 들어 선택한 영역으로 여러 HTTP요청을 만드는 웹 페이지를 제작함으로써 이론적으로 백만명 이상의 방문자(220)날짜 요청 HTTP를 통해 HTTPSvs. 도착하기 때문일 것입니다;후자는 이전에 녹화된 이진법"비트"설립되 e.게 구분할 수 있어aHSTS [23]헤더를 경유합니다.

브라우저 지원

Settings page for HTTPS Strict Transport Security within Chromium 45, showing the status of the security policy for the domain "en.wikipedia.org".

도입의 베스트 프랙티스

실제 전개에 따라서는 베스트 프랙티스에 따라 회피할 수 있는 특정 위협(cookie injection attack 등)이 있습니다.

  • HSTS 호스트는 최상위 도메인 이름으로 HSTS 정책을 선언해야 합니다.예를 들어, https://sub.example.com의 HSTS 호스트도 https://example.com의 HSTS 헤더로 응답해야 합니다.머리글에는 다음 명령어가 지정되어 있어야 합니다.includeSubDomains지시.[31]
  • HSTS 배치와 더불어 https://www.example.com의 호스트에는 부모 도메인의 HSTS가 설정되어 있는지 확인하고 부모 도메인에 대한 참조를 주입하는 MITM에 의해 실행되는 잠재적인 쿠키 주입 공격으로부터 사용자를 보호하기 위해 https://example.com의 리소스에 대한 요구가 포함되어 있어야 합니다.http://nonexistentpeer.example.com)[32]를 참조해 주세요.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c d "Strict-Transport-Security". MDN Web Docs. Mozilla. Archived from the original on 20 March 2020. Retrieved 31 January 2018.
  2. ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). "HSTS Policy". HTTP Strict Transport Security (HSTS). IETF. doi:10.17487/RFC6797. RFC 6797. Retrieved 31 January 2018. 2019년 5월 28일 Wayback Machine에서 보관
  3. ^ "[websec] Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)". 2 October 2012. Archived from the original on 29 January 2017. Retrieved 2 October 2012.
  4. ^ Jeff Hodges (30 June 2010). "Re: [HASMAT] "STS" moniker (was: IETF BoF @IETF-78 Maastricht: HASMAT...)". Archived from the original on 2 February 2017. Retrieved 22 July 2010.
  5. ^ "Strict Transport Security -06". 18 December 2009. Archived from the original on 21 February 2017. Retrieved 23 December 2009.
  6. ^ "Strict Transport Security -05". 18 September 2009. Archived from the original on 24 February 2020. Retrieved 19 November 2009.
  7. ^ "ForceHTTPS: Protecting High-Security Web Site from Network Attacks". April 2008. Archived from the original on 28 February 2020. Retrieved 19 November 2009.
  8. ^ Hodges, Jeff; Steinguebl, Andy (29 October 2010). "The Need for Coherent Web Security Policy Framework(s)". Archived from the original on 14 August 2017. Retrieved 21 November 2012.
  9. ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). "Section 5. HSTS Mechanism Overview". RFC 6797. IETF. Archived from the original on 28 May 2019. Retrieved 21 November 2012.
  10. ^ a b Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). "2.4. Threat Model". RFC 6797. IETF. Archived from the original on 28 May 2019. Retrieved 21 November 2012.
  11. ^ "New Tricks For Defeating SSL In Practice" (PDF). Archived (PDF) from the original on 30 December 2014. Retrieved 15 March 2012. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  12. ^ YouTube에서의 SSL 스트립을 사용한SSL의 무효화
  13. ^ a b Adam Langley (8 July 2010). "Strict Transport Security". The Chromium Projects. Archived from the original on 1 September 2019. Retrieved 22 July 2010.
  14. ^ a b c David Keeler (1 November 2012). "Preloading HSTS". Mozilla Security Blog. Archived from the original on 24 February 2020. Retrieved 6 February 2014.
  15. ^ a b Bell, Mike; Walp, David (16 February 2015). "HTTP Strict Transport Security comes to Internet Explorer". Archived from the original on 15 November 2015. Retrieved 16 February 2015.
  16. ^ Jeff Hodges (31 October 2010). "Firesheep and HSTS (HTTP Strict Transport Security)". Archived from the original on 23 June 2016. Retrieved 8 March 2011.
  17. ^ Jose Selvi (17 October 2014). "Bypassing HTTP Strict Transport Security" (PDF). Archived (PDF) from the original on 22 October 2014. Retrieved 22 October 2014.
  18. ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (November 2012). "Section 14.6. Bootstrap MITM Vulnerability". RFC 6797. IETF. doi:10.17487/RFC6797. Archived from the original on 28 May 2019. Retrieved 21 November 2012.
  19. ^ "Chromium HSTS Preloaded list". cs.chromium.org. Archived from the original on 18 February 2020. Retrieved 10 July 2019.
  20. ^ Butcher, Simon (11 September 2011). "HTTP Strict Transport Security". Archived from the original on 26 April 2019. Retrieved 27 March 2012.
  21. ^ Ali, Junade (20 October 2017). "Performing & Preventing SSL Stripping: A Plain-English Primer". Cloudflare Blog. Archived from the original on 14 December 2019. Retrieved 7 December 2017.
  22. ^ Maksutov, A. A.; Cherepanov, I. A.; Alekseev, M. S. (2017). 2017 Siberian Symposium on Data Science and Engineering (SSDSE). pp. 84–87. doi:10.1109/SSDSE.2017.8071970. ISBN 978-1-5386-1593-5. S2CID 44866769.
  23. ^ "The HSTS super cookie forcing you to choose: "privacy or security?" -". sophos.com. 2 February 2015. Archived from the original on 11 February 2020. Retrieved 1 December 2015.
  24. ^ The Chromium Developers (17 November 2010). "Strict Transport Security - The Chromium Projects". Archived from the original on 20 March 2020. Retrieved 17 November 2010.
  25. ^ Jeff Hodges (18 September 2009). "fyi: Strict Transport Security specification". Archived from the original on 29 February 2020. Retrieved 19 November 2009.
  26. ^ Opera Software ASA (23 April 2012). "Web specifications support in Opera Presto 2.10". Archived from the original on 20 June 2018. Retrieved 8 May 2012.
  27. ^ @agl__ (Adam Langley). "Confirmed. See ~/Library/Cookies/HSTS.plist. Includes Chromium preloads as of some date and processes HSTS headers". on Twitter. Archived from the original on 9 May 2019. Retrieved 20 December 2013.
  28. ^ "HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7". windows.com. Archived from the original on 27 November 2019. Retrieved 12 June 2015.
  29. ^ "Internet Explorer Web Platform Status and Roadmap". Archived from the original on 29 June 2015. Retrieved 14 April 2014.
  30. ^ "Project Spartan and the Windows 10 January Preview Build - IEBlog". Archived from the original on 29 November 2019. Retrieved 23 January 2015.
  31. ^ Hodges; et al. "HTTP Strict Transport Security (HSTS) 6.1.2". ietf.org. Archived from the original on 22 July 2019. Retrieved 11 November 2016.
  32. ^ Hodges, J.; Jackson, C.; Barth, A. (2012). "RFC 6797 - HTTP Strict Transport Security (HSTS)". IETF Tools. doi:10.17487/RFC6797. Archived from the original on 28 May 2019. Retrieved 28 May 2019.

외부 링크