HTTP 완전 전송 보안
HTTP Strict Transport SecurityHTTP 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]
- 웹 응용 프로그램을 참조하는 모든 보안되지 않은 링크를 자동으로 보안 링크로 변환합니다(예:
http://example.com/some/page/
로 변경된다.https://example.com/some/page/
(서버에 액세스 하기 전에) - 접속의 보안을 확보할 수 없는 경우(서버의 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]헤더를 경유합니다.
브라우저 지원
- 버전 4.0.211.0[24][25] 이후 Chromium 및 Google Chrome
- 파이어폭스 버전4 [1]이후부터 파이어폭스17에서는 HSTS를 [14]지원하는 웹 사이트 목록이 Mozilla에 통합되어 있습니다.
- 버전[26] 12 이후의 오페라
- OS X Mavericks 이후 Safari (버전 10.9,[27] 2013년 말)
- KB3058515가 설치된 Windows 8.1 및 Windows 7의 Internet Explorer 11(2015년 [28]6월 Windows Update로 출시)
- Windows[29][30] 10의 Microsoft Edge 및 Internet Explorer 11
- BlackBerry OS 10.3.3 이후 BlackBerry 10 Browser 및 WebView.
도입의 베스트 프랙티스
실제 전개에 따라서는 베스트 프랙티스에 따라 회피할 수 있는 특정 위협(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]를 참조해 주세요.
「 」를 참조해 주세요.
- 콘텐츠 보안 정책
- .dev TLD - 기본적으로 HSTS 프리로드 목록에 포함된 Google 작동 TLD
- HTTP 공개 키 핀 접속
레퍼런스
- ^ a b c d "Strict-Transport-Security". MDN Web Docs. Mozilla. Archived from the original on 20 March 2020. Retrieved 31 January 2018.
- ^ 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에서 보관
- ^ "[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.
- ^ 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.
- ^ "Strict Transport Security -06". 18 December 2009. Archived from the original on 21 February 2017. Retrieved 23 December 2009.
- ^ "Strict Transport Security -05". 18 September 2009. Archived from the original on 24 February 2020. Retrieved 19 November 2009.
- ^ "ForceHTTPS: Protecting High-Security Web Site from Network Attacks". April 2008. Archived from the original on 28 February 2020. Retrieved 19 November 2009.
- ^ 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.
- ^ 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.
- ^ 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.
- ^ "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=
(도움말) - ^ YouTube에서의 SSL 스트립을 사용한SSL의 무효화
- ^ 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.
- ^ 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.
- ^ 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.
- ^ Jeff Hodges (31 October 2010). "Firesheep and HSTS (HTTP Strict Transport Security)". Archived from the original on 23 June 2016. Retrieved 8 March 2011.
- ^ Jose Selvi (17 October 2014). "Bypassing HTTP Strict Transport Security" (PDF). Archived (PDF) from the original on 22 October 2014. Retrieved 22 October 2014.
- ^ 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.
- ^ "Chromium HSTS Preloaded list". cs.chromium.org. Archived from the original on 18 February 2020. Retrieved 10 July 2019.
- ^ Butcher, Simon (11 September 2011). "HTTP Strict Transport Security". Archived from the original on 26 April 2019. Retrieved 27 March 2012.
- ^ 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.
- ^ 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.
- ^ "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.
- ^ The Chromium Developers (17 November 2010). "Strict Transport Security - The Chromium Projects". Archived from the original on 20 March 2020. Retrieved 17 November 2010.
- ^ Jeff Hodges (18 September 2009). "fyi: Strict Transport Security specification". Archived from the original on 29 February 2020. Retrieved 19 November 2009.
- ^ 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.
- ^ @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.
- ^ "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.
- ^ "Internet Explorer Web Platform Status and Roadmap". Archived from the original on 29 June 2015. Retrieved 14 April 2014.
- ^ "Project Spartan and the Windows 10 January Preview Build - IEBlog". Archived from the original on 29 November 2019. Retrieved 23 January 2015.
- ^ 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.
- ^ 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.
외부 링크
- RFC 6797 - HTTP Strict Transport Security(HSTS)
- IETF WebSec 작업 그룹
- 현재 262 보안: 엄격한 전송 보안
- Open Web Application Security Project(OWASP): HSTS 설명
- 온라인 브라우저 HSTS 및 공개 키 핀 연결 테스트
- 웹 서버의 온라인 HSTS 테스트
- Google Chrome, Mozilla Firefox, Safari, IE 11 및 Edge용 HSTS 프리로드 전송
- Cromium HSTS 프리로드 리스트
- MDN Web 문서에서의 엄밀한 트랜스포트 보안
- HSTS 정책에 관한 모든 갱신