HTTPS

HTTPS
인터넷 프로토콜 모음
응용 계층
수송층
인터넷 계층
링크 계층
HTTP
리퀘스트방법
머리글 필드
대응상태코드
보안 접근 제어 방법
보안 취약점

HTTP(Hypertext Transfer Protocol Secure)는 HTTP(Hypertext Transfer Protocol)의 확장입니다.컴퓨터 네트워크를 통한 안전한 통신을 위해 암호화를 사용하며, 인터넷에서 널리 사용됩니다.[1][2]HTTPS에서 통신 프로토콜은 TLS(Transport Layer Security) 또는 이전 SSL(Secure Sockets Layer)을 사용하여 암호화됩니다.따라서 프로토콜은 TLS를 통한 HTTP [3]또는 SSL을 통한 HTTP라고도 합니다.

HTTPS의 주요 동기는 액세스된 웹 사이트의 인증과 전송 중에 교환된 데이터의 개인 정보 보호 및 무결성입니다.중간자 공격으로부터 보호하며, 클라이언트와 서버 간 통신의 양방향 블록 암호화를 통해 통신을 도청 및 변조로부터 보호합니다.[4][5]HTTPS의 인증 측면에서는 신뢰할 수 있는 제3자가 서버측 디지털 인증서에 서명해야 합니다.이것은 역사적으로 많은 비용이 드는 작업이었는데, 이는 완전히 인증된 HTTPS 연결이 대개 월드 와이드 웹의 보안된 결제 거래 서비스 및 기타 기업 정보 시스템에서만 발견된다는 것을 의미했습니다.2016년, Electronic Frontier Foundation이 웹 브라우저 개발자들의 지원을 받아 진행한 캠페인으로 인해 프로토콜이 더욱 널리 퍼지게 되었습니다.[6]현재 HTTPS는 원래의 비보안 HTTP보다 웹 사용자가 더 자주 사용하며, 주로 모든 유형의 웹 사이트에서 페이지 인증을 보호하고, 계정을 보호하며, 사용자 통신, ID 및 웹 브라우징을 비공개로 유지합니다.

개요

자세한 정보:전송 계층 보안
HTTPS 체계 및 WWW 도메인 이름 레이블로 시작하는 URL

URI(Uniform Resource Identifier) 방식 HTTPS는 HTTP 방식과 동일한 사용 구문을 갖습니다.그러나 HTTPS는 트래픽을 보호하기 위해 SSL/TLS의 추가 암호화 계층을 사용하도록 브라우저에 신호를 보냅니다.SSL/TLS는 통신의 한 쪽만 인증되더라도 어느 정도 보호를 제공할 수 있기 때문에 HTTP에 특히 적합합니다.이는 일반적으로 서버만 인증(클라이언트가 서버의 인증서를 검사함)되는 인터넷을 통한 HTTP 트랜잭션의 경우입니다.

HTTPS는 안전하지 않은 네트워크를 통해 안전한 채널을 만듭니다.이를 통해 적절한 암호 모음이 사용되고 서버 인증서가 검증되고 신뢰할 수 있는 경우 도청자 및 중간자 공격으로부터 합리적인 보호가 가능합니다.

HTTPS는 HTTP를 전적으로 TLS 위에 올려놓기 때문에 기본 HTTP 프로토콜 전체를 암호화할 수 있습니다.여기에는 요청의 URL, 쿼리 매개 변수, 헤더 및 쿠키(종종 사용자에 대한 식별 정보를 포함함)가 포함됩니다.그러나 웹 사이트 주소와 포트 번호는 필수적으로 기본 TCP/IP 프로토콜의 일부이기 때문에 HTTPS는 이러한 노출을 보호할 수 없습니다.실제로 이것은 도청자들이 정확하게 구성된 웹 서버에서도 웹 서버의 IP 주소와 포트 번호, 그리고 때로는 사용자가 통신하고 있는 도메인 이름(예: www.example.org , 그러나 나머지 URL은 제외), 그리고 전송된 데이터의 양과 통신 기간을 유추할 수 있다는 것을 의미합니다.의사소통의 [4]내용은 아니지만요

웹 브라우저는 소프트웨어에 미리 설치된 인증 기관에 따라 HTTPS 웹 사이트를 신뢰하는 방법을 알고 있습니다.이런 방식으로 인증 기관은 웹 브라우저 작성자가 유효한 인증서를 제공하도록 신뢰하게 됩니다.따라서 사용자는 웹 사이트에 대한 HTTPS 연결을 신뢰해야 합니다. 이는 다음 사항이 모두 사실인 경우에만 해당됩니다.

  • 사용자는 브라우저를 호스팅하는 장치와 브라우저 자체를 얻는 방법이 손상되지 않는다고 신뢰합니다(즉, 공급망 공격이 없음).
  • 사용자는 브라우저 소프트웨어가 올바르게 미리 설치된 인증 기관과 함께 HTTPS를 올바르게 구현한다고 신뢰합니다.
  • 사용자는 인증 기관을 신뢰하여 합법적인 웹 사이트에 대해서만 보증합니다(예: 인증 기관이 손상되지 않고 인증서를 잘못 발급하지 않음).
  • 웹사이트는 유효한 인증서를 제공하는데, 이는 신뢰할 수 있는 기관에서 서명했다는 것을 의미합니다.
  • 인증서는 웹 사이트를 올바르게 식별합니다(예: 브라우저가 "https://example.com "을 방문할 때 수신된 인증서는 다른 엔티티가 아닌 "example.com "에 대해 올바른 인증서입니다).
  • 사용자는 프로토콜의 암호화 계층(SSL/TLS)이 도청자로부터 충분히 안전하다고 신뢰합니다.

HTTPS는 특히 안전하지 않은 네트워크와 변조의 대상이 될 수 있는 네트워크에서 중요합니다.공중 Wi-Fi 액세스 포인트와 같은 안전하지 않은 네트워크는 동일한 로컬 네트워크에 있는 모든 사람이 패킷을 탐지하고 HTTPS로 보호되지 않는 민감한 정보를 발견할 수 있도록 합니다. 또한 일부 무료 및 유료 무선랜 네트워크는 다른 웹사이트에 자신의 광고를 제공하기 위해 패킷 주입에 관여하여 웹페이지를 변조하는 것이 관찰되었습니다.이 방식은 웹 페이지에 악성 프로그램을 주입하고 사용자의 개인 정보를 도용하는 등 여러 가지 방식으로 악의적으로 악용될 수 있습니다.[7]

HTTPS는 Tor 네트워크를 통한 연결에도 중요합니다. 그렇지 않으면 악의적인 Tor 노드가 자신을 통과하는 콘텐츠를 안전하지 않은 방식으로 손상시키거나 변경하여 연결에 악성 프로그램을 주입할 수 있기 때문입니다.이것이 Electronic Frontier Foundation과 Tor Project가 Tor Browser에 포함된 [4]HTTPS Everywhere의 개발을 시작하게 된 한 가지 이유입니다.[8]

전 세계적인 대량 사찰과 범죄자들의 개인정보 탈취에 대한 정보가 많아지면서 인터넷 연결 형태와 상관없이 모든 웹사이트에서 HTTPS 보안 사용이 점점 중요해지고 있습니다.[9][10]사용자가 방문하는 개별 페이지에 대한 메타데이터는 민감한 것으로 간주되지 않을 수 있지만, 집계되면 사용자에 대한 많은 것이 노출되고 사용자의 프라이버시가 손상될 수 있습니다.[11][12][13]

또한 HTTPS를 배포하면 페이지 로드 시간, 크기 및 지연 시간을 줄이기 위해 설계된 새로운 HTTP 버전인 HTTP/2 및 HTTP/3(및 그 이전 버전인 SPDY 및 QUIC)을 사용할 수 있습니다.

HTTPS(HTTP Strict Transport Security)를 사용하여 중간자 공격, 특히 SSL 제거로부터 사용자를 보호하는 것이 좋습니다.[13][14]

HTTPS는 RFC 2660에서 지정한 잘 사용되지 않는 S-HTTP(Secure HTTP)와 혼동해서는 안 됩니다.

웹사이트에서의 사용법

2018년 4월 기준, Alexa 상위 1,000,000개 웹 사이트의 33.2%가 HTTPS를 기본값으로[15] 사용하고 있으며, 페이지 로드의 70%(Firefox Telemetry 측정)가 HTTPS를 사용하고 있습니다.[16][17] 2022년 12월 기준, 인터넷에서 가장 인기 있는 135,422개 웹 사이트 중 58.4%가 HTTPS를 안전하게 구현하고 있지만, 2018년 TLS 1.3이 출시되었음에도 불구하고 채택이 더뎌 많은 사이트가 여전히 t에 남아 있습니다.더 오래된 TLS 1.2 프로토콜입니다.[18]

브라우저 통합

대부분의 브라우저는 잘못된 인증서를 받으면 경고를 표시합니다.이전 브라우저는 잘못된 인증서를 가진 사이트에 연결할 경우 사용자에게 계속할지 여부를 묻는 대화 상자를 표시합니다.최신 브라우저는 전체 창에 경고를 표시합니다.최신 브라우저는 주소 표시줄에 사이트의 보안 정보를 표시합니다.확장 유효성 검사 인증서는 인증서 정보에 법적 개체를 표시합니다.대부분의 브라우저는 암호화된 내용과 암호화되지 않은 내용이 혼재된 사이트를 방문할 때 사용자에게 경고를 표시합니다.또한 많은 웹 필터가 금지된 웹 사이트를 방문할 때 보안 경고를 반환합니다.

서로 다른 종류의 SSL/TLS 인증서 비교
(Firefox를 예로 들어)
  • Many web browsers, including Firefox (shown here), use the address bar to tell the user that their connection is secure, an Extended Validation Certificate should identify the legal entity for the certificate.

    Firefox(여기에 표시된)를 포함한 많은 웹 브라우저는 주소 표시줄을 사용하여 사용자에게 연결이 안전하다는 것을 알려줍니다. 확장 유효성 검사 인증서는 인증서의 법적 개체를 식별해야 합니다.

  • When accessing a site only with a common certificate, on the address bar of Firefox and other browsers, a "lock" sign appears.

    일반 인증서만으로 사이트에 액세스할 경우 Firefox 및 기타 브라우저의 주소 표시줄에 "잠금" 기호가 나타납니다.

  • Most web browsers alert the user when visiting sites that have invalid security certificates.

    대부분의 웹 브라우저는 잘못된 보안 인증서를 가진 사이트를 방문할 때 사용자에게 경고합니다.

Electronic Frontier Foundation은 "이상적인 세계에서는 모든 웹 요청이 HTTPS로 기본 설정될 수 있다"며 Mozilla Firefox, Google Chrome, Chrome 및 Android용 HTTPS Everywhere라고 불리는 추가 기능을 제공했습니다. 이 기능은 자주 사용하는 수백 개의 웹 사이트에 기본적으로 HTTPS를 지원합니다.[19][20]

웹 브라우저에서 HTTPS 콘텐츠만 로드하도록 강제하는 것은 버전 83부터 Firefox에서 지원되었습니다.[21]버전 94부터 구글 크롬은 브라우저 설정을 전환하면 "항상 안전한 연결을 사용"할 수 있습니다.[22][23]

보안.

주요 기사:트랜스포트 레이어 보안 § 보안

HTTPS의 보안은 기본 TLS의 보안으로, 일반적으로 단기 세션 키를 생성하기 위해 장기간 공개 키와 개인 키를 사용하며, 클라이언트와 서버 간의 데이터 흐름을 암호화하는 데 사용됩니다.X.509 인증서는 서버(및 클라이언트)를 인증하는 데 사용됩니다.따라서 인증서와 소유자와의 관계를 확인하고 인증서의 유효성을 확인하기 위해서는 인증기관과 공개키 인증서가 필요하며, 인증서의 유효성을 확인하고 서명하여 관리해야 합니다.이것이 신뢰망을 통해 신원을 확인하는 것보다 더 유익할 수 있지만, 2013년 대규모 감시 공개는 중간자 공격을 허용하는 잠재적 약점으로 인증 기관에 주목했습니다.[24][25]이러한 맥락에서 중요한 속성은 미래에 장기간 비밀키나 비밀번호가 손상될 경우 과거에 기록된 암호화된 통신을 검색하고 해독할 수 없도록 보장하는 순방향 비밀입니다.모든 웹 서버가 순방향 비밀을 제공하는 것은 아닙니다.[26][needs update]

HTTPS를 효과적으로 사용하려면 사이트가 HTTPS를 통해 완전히 호스팅되어야 합니다. 사이트의 일부 콘텐츠가 HTTP(예를 들어 스크립트 또는 이미지)를 통해 로드되거나 로그인 페이지와 같은 민감한 정보를 포함하는 특정 페이지만 HTTPS를 통해 로드되고 나머지 사이트는 일반 HTTP를 통해 로드되는 경우사용자는 공격과 감시에 취약하게 됩니다.또한 HTTPS를 통해 제공되는 사이트의 쿠키에는 보안 속성이 활성화되어 있어야 합니다.중요한 정보가 있는 사이트에서는 HTTPS 대신 HTTP를 사용하여 해당 사이트에 액세스할 때마다 사용자와 세션이 노출됩니다.[13]

테크니컬

HTTP와의 차이점

HTTPS URL은 "https://"로 시작하여 기본적으로 포트 443을 사용하는 반면, HTTP URL은 "http://"로 시작하여 기본적으로 포트 80을 사용합니다.

HTTP는 암호화되지 않으므로 중간자 및 도청 공격에 취약하므로 공격자가 웹 사이트 계정 및 중요 정보에 액세스하고 웹 페이지를 수정하여 악성 프로그램이나 광고를 주입할 수 있습니다.HTTPS는 이러한 공격에 견딜 수 있도록 설계되었으며, 이전 버전의 SSL을 사용하는 HTTPS 구현을 제외하고는 이러한 공격에 대해 안전한 것으로 간주됩니다.

네트워크 계층

HTTP는 TCP/IP 모델의 최상위 계층인 응용 계층에서 작동하며, 전송 전에 HTTP 메시지를 암호화하고 도착 시 메시지를 해독하는 TLS 보안 프로토콜(동일 계층의 하위 계층으로 작동)도 작동합니다.엄밀하게 말하면 HTTPS는 별개의 프로토콜이 아니라 암호화된 SSL/TLS 연결을 통해 일반 HTTP를 사용하는 것을 말합니다.

HTTPS는 HTTP 헤더와 요청/응답 데이터를 포함한 모든 메시지 내용을 암호화합니다.아래 제한 사항 섹션에서 설명한 CCA 암호화 공격 가능성을 제외하고 공격자는 도메인 이름 및 IP 주소와 함께 두 당사자 간에 연결이 발생하고 있음을 최대로 파악할 수 있어야 합니다.

서버설정

HTTPS 연결을 허용하는 웹 서버를 준비하려면 관리자가 웹 서버에 대한 공개 키 인증서를 만들어야 합니다.웹 브라우저가 경고 없이 인증서를 수락하려면 신뢰할 수 있는 인증 기관에서 인증서에 서명해야 합니다.기관은 인증서 보유자가 인증서를 제시하는 웹 서버의 운영자임을 인증합니다.웹 브라우저는 일반적으로 주요 인증 기관의 서명 인증서 목록과 함께 배포되어 서명된 인증서를 확인할 수 있습니다.

인증서 획득 중

확장 유효성 검사 인증서를 포함한 여러 유형의 유료 SSL/TLS 인증서를 제공하는 다수의 상용 인증 기관이 존재합니다.

2016년 4월 출시된 Let's Encrypt는 기본 SSL/TLS 인증서를 웹사이트에 전달하는 무료 자동화 서비스를 제공합니다.[27][28]Electronic Frontier Foundation에 따르면, Let's Encrypt는 HTTP에서 HTTPS로의 전환을 "명령 하나를 내리거나 버튼 하나를 클릭하는 것만큼" 쉽게 만들 것입니다.[29]이제 대부분의 웹 호스트와 클라우드 공급자는 Let's Encrypt를 활용하여 고객에게 무료 인증서를 제공합니다.

액세스 제어로 사용

인증된 사용자로 웹 서버에 대한 접근을 제한하기 위해 클라이언트 인증에 시스템을 사용할 수도 있습니다.이를 위해 사이트 관리자는 일반적으로 각 사용자에 대한 인증서를 만들고, 이 인증서를 사용자가 브라우저로 로드합니다.일반적으로 인증서에는 인증된 사용자의 이름과 전자우편 주소가 포함되어 있으며, 각 연결에서 서버가 자동으로 확인하여 사용자의 신원을 확인하므로 암호조차 필요하지 않을 수 있습니다.

비밀(개인)키가 손상된 경우

이러한 맥락에서 중요한 속성은 PFS(Perfect Forward Secretary)입니다.HTTPS 세션을 설정하는 데 사용되는 장기적인 비대칭 비밀 키 중 하나를 소유한다고 해서 나중에라도 대화를 해독하는 단기 세션 키를 쉽게 도출해서는 안 됩니다.디피–헬만 키 교환(DHE)과 타원 곡선 디피-헬만 키 교환(ECDHE)은 2013년에 그 속성을 가진 것으로 알려진 유일한 계획입니다.2013년에는 파이어폭스, 오페라, 크롬 브라우저 세션 중 30%만이 이를 사용했고, 애플 사파리와 마이크로소프트 인터넷 익스플로러 세션 중 거의 0%가 이를 사용했습니다.[26]2018년 8월에 발표된 TLS 1.3은 순방향 비밀 없이 암호에 대한 지원을 중단했습니다.2019년 2월 현재 조사 대상 웹 서버의 96.6%가 어떤 형태로든 순방향 비밀을 지지하고 있으며 52.1%는 대부분의 브라우저에서 순방향 비밀을 사용할 것입니다.[30]2023년 7월 현재 조사 대상 웹 서버의 99.6%가 어떤 형태로든 순방향 비밀을 지지하고 있으며 75.2%는 대부분의 브라우저에서 순방향 비밀을 사용할 것입니다.[31]

인증서 해지
주요 기사:인증서 해지

인증서가 만료되기 전에 취소될 수 있습니다. 예를 들어 개인 키의 비밀이 손상되었기 때문입니다.Windows Vista의[34] Firefox,[32] Opera [33]및 Internet Explorer와 같은 최신 버전의 인기 브라우저는 OCSP(Online Certificate Status Protocol)를 구현하여 그렇지 않은지 확인합니다.브라우저는 OCSP(Online Certificate Status Protocol)를 통해 인증서의 일련 번호를 인증 기관 또는 대리인에게 전송하고, 인증 기관은 이에 응답하여 인증서가 여전히 유효한지 여부를 브라우저에 알려줍니다.[35]CA는 또한 CRL을 발급하여 사람들에게 이러한 인증서가 취소되었음을 알릴 수도 있습니다.CRL은 CA/Browser 포럼에서 더 이상 필요하지 않지만 여전히 CA에서 널리 사용되고 있습니다.[36]대부분의 인터넷 해지 상태는 인증서 만료 후 곧 사라집니다.[37]

한계

SSL(Secure Sockets Layer) 및 TLS(Transport Layer Security) 암호화는 단순 모드와 상호 모드의 두 가지 모드로 구성할 수 있습니다.단순 모드에서는 서버에서만 인증이 수행됩니다.상호 버전에서는 사용자 인증을 위해 웹 브라우저에 개인 클라이언트 인증서를 설치해야 합니다.[38]어느 경우든 보호 수준은 소프트웨어 구현의 정확성과 사용 중인 암호화 알고리즘에 따라 달라집니다.

SSL/TLS는 웹 크롤러에 의한 사이트 인덱싱을 방지하지 않으며, 경우에 따라 가로챈 요청/응답 크기만 알고 암호화된 리소스의 URI를 유추할 수 있습니다.[39]이를 통해 공격자는 일반 텍스트(공개적으로 사용 가능한 정적 컨텐츠) 및 암호화된 텍스트(정적 컨텐츠의 암호화된 버전)에 액세스하여 암호화 공격을 허용할 수 있습니다.

TLS는 HTTP보다 낮은 프로토콜 수준에서 작동하고 상위 프로토콜에 대한 지식이 없기 때문에 TLS 서버는 특정 주소 및 포트 조합에 대해 하나의 인증서만 엄격하게 제시할 수 있습니다.[40]이전에는 HTTPS에서 이름 기반 가상 호스팅을 사용할 수 없었음을 의미했습니다. SNI(Server Name Indication)라는 솔루션이 존재하는데, 이 솔루션은 연결을 암호화하기 전에 호스트 이름을 서버로 전송하지만, 이전 브라우저에서는 이 확장 기능을 지원하지 않습니다.Windows Vista의 Firefox 2, Opera 8, Apple Safari 2.1, Google Chrome 6, Internet Explorer 7부터 SNI 지원이 가능합니다.[41][42][43]

건축적 관점에서:

  • SSL/TLS 연결은 TLS 연결을 시작하는 첫 번째 전면 시스템에 의해 관리됩니다.어떤 이유로든(라우팅, 트래픽 최적화 등), 이 프런트 머신이 애플리케이션 서버가 아니므로 데이터를 해독해야 하는 경우, 애플리케이션 서버에 사용자 인증 정보나 인증서를 전파하기 위한 솔루션을 찾아야 하며, 이를 위해서는 누가 연결될지 알아야 합니다.
  • 상호 인증이 있는 SSL/TLS의 경우 연결을 시작하는 첫 번째 서버가 SSL/TLS 세션을 관리합니다.체인 서버를 따라 암호화를 전파해야 하는 상황에서는 세션 시간 초과 관리를 구현하기가 매우 까다로워집니다.
  • 상호 SSL/TLS를 사용하면 보안이 극대화되지만, 클라이언트 측에서는 서버 세션이 만료될 때까지 기다리거나 모든 관련 클라이언트 응용 프로그램을 닫는 것 외에는 SSL/TLS 연결을 제대로 종료하고 사용자의 연결을 끊을 수 있는 방법이 없습니다.

SSL 스트리핑이라고 불리는 정교한 유형의 중간자 공격은 2009년 블랙햇 컨퍼런스에서 발표되었습니다.이러한 유형의 공격은 HTTPS가 제공하는 보안을 변경하여 물리칩니다.https:에 연결시키다http:링크는 실제로 브라우저 인터페이스에 "https"를 입력하는 인터넷 사용자가 거의 없다는 점을 이용합니다. 링크를 클릭하면 안전한 사이트에 도달하므로 실제로 HTTP를 사용할 때 HTTPS를 사용하는 것으로 속아 넘어갑니다.그런 다음 공격자는 클라이언트와 명확하게 통신합니다.[44]이로 인해 HTTP Strict Transport Security라는 HTTP 대책이 개발되었습니다.

HTTPS는 다양한 트래픽 분석 공격에 취약한 것으로 나타났습니다.트래픽 분석 공격은 암호화된 트래픽 자체에 대한 속성을 추론하기 위해 트래픽의 타이밍과 크기의 변화에 의존하는 측면 채널 공격의 한 유형입니다.SSL/TLS 암호화는 트래픽의 내용을 변경시키지만 트래픽의 크기와 타이밍에는 최소한의 영향을 미치기 때문에 트래픽 분석이 가능합니다.2010년 5월, 마이크로소프트 리서치와 인디애나 대학교 연구원들의 연구 논문은 패킷 크기와 같은 측면 채널에서 세부적인 민감한 사용자 데이터를 유추할 수 있다는 것을 발견했습니다.연구원들은 의료, 세금, 투자 및 웹 검색 분야에서 HTTPS 보호 기능을 사용함에도 불구하고 도청자가 사용자의 질병/약물/수술, 가족 수입, 투자 비밀 등을 추론할 수 있다는 사실을 발견했습니다.[45]본 연구는 HTTPS가 트래픽 분석에 취약하다는 것을 보여주었지만, 저자들이 제시한 접근 방식은 수동 분석이 필요했고 특히 HTTPS에 의해 보호되는 웹 애플리케이션에 초점을 맞추었습니다.

Google, Yahoo! 및 Amazon을 포함한 대부분의 최신 웹 사이트에서 HTTPS를 사용한다는 사실은 사용자가 HTTPS 리소스를 열려는 경우 Wi-Fi 핫스팟 로그인 페이지가 로드되지 않기 때문에 공용 Wi-Fi 핫스팟에 액세스하려는 많은 사용자에게 문제를 야기합니다.[46]neverssl.com 과 같은 여러 웹 사이트에서는 HTTP를 통해 항상 액세스할 수 있도록 보장합니다.

역사

주요 기사:IMT2000 3GPP - 전송계층 보안 § 기록 및 개발

Netscape Communications는 1994년에 Netscape Navigator 웹 브라우저를 위한 HTTPS를 만들었습니다.[48]원래 HTTPS는 SSL 프로토콜과 함께 사용되었습니다.SSL이 TLS(Transport Layer Security)로 발전하면서, HTTPS는 2000년 5월에 RFC 2818에 의해 공식적으로 지정되었습니다.구글은 2018년 2월 크롬 브라우저가 HTTP 사이트를 2018년 7월 이후 "보안되지 않음"으로 표시할 것이라고 발표했습니다.[49]이러한 조치는 월드 와이드 웹을 보다 안전하게 만들기 위한 노력의 일환으로 웹사이트 소유자들이 HTTPS를 구현하도록 장려하기 위한 것이었습니다.

참고 항목

참고문헌

  1. ^ "Secure your site with HTTPS". Google Support. Google Inc. Archived from the original on 1 March 2015. Retrieved 20 October 2018.
  2. ^ "What is HTTPS?". Comodo CA Limited. Archived from the original on 12 February 2015. Retrieved 20 October 2018. Hyper Text Transfer Protocol Secure (HTTPS) is the secure version of HTTP [...]
  3. ^ "https URI Scheme". HTTP Semantics. IETF. June 2022. sec. 4.2.2. doi:10.17487/RFC9110. RFC 9110.
  4. ^ a b c "HTTPS Everywhere FAQ". 8 November 2016. Archived from the original on 14 November 2018. Retrieved 20 October 2018.
  5. ^ "Usage Statistics of Default protocol https for Websites, July 2019". w3techs.com. Archived from the original on 1 August 2019. Retrieved 20 July 2019.
  6. ^ "Encrypting the Web". Electronic Frontier Foundation. Archived from the original on 18 November 2019. Retrieved 19 November 2019.
  7. ^ "Hotel Wifi JavaScript Injection". JustInsomnia. 3 April 2012. Archived from the original on 18 November 2018. Retrieved 20 October 2018.
  8. ^ The Tor Project, Inc. "What is Tor Browser?". TorProject.org. Archived from the original on 17 July 2013. Retrieved 30 May 2012.
  9. ^ Konigsburg, Eitan; Pant, Rajiv; Kvochko, Elena (13 November 2014). "Embracing HTTPS". The New York Times. Archived from the original on 8 January 2019. Retrieved 20 October 2018.
  10. ^ Gallagher, Kevin (12 September 2014). "Fifteen Months After the NSA Revelations, Why Aren't More News Organizations Using HTTPS?". Freedom of the Press Foundation. Archived from the original on 10 August 2018. Retrieved 20 October 2018.
  11. ^ "HTTPS as a ranking signal". Google Webmaster Central Blog. Google Inc. 6 August 2014. Archived from the original on 17 October 2018. Retrieved 20 October 2018. You can make your site secure with HTTPS (Hypertext Transfer Protocol Secure) [...]
  12. ^ Grigorik, Ilya; Far, Pierre (26 June 2014). "Google I/O 2014 - HTTPS Everywhere". Google Developers. Archived from the original on 20 November 2018. Retrieved 20 October 2018.
  13. ^ a b c "How to Deploy HTTPS Correctly". 15 November 2010. Archived from the original on 10 October 2018. Retrieved 20 October 2018.
  14. ^ "HTTP Strict Transport Security". Mozilla Developer Network. Archived from the original on 19 October 2018. Retrieved 20 October 2018.
  15. ^ "HTTPS usage statistics on top 1M websites". StatOperator.com. Archived from the original on 9 February 2019. Retrieved 20 October 2018.
  16. ^ "Let's Encrypt Stats". LetsEncrypt.org. Archived from the original on 19 October 2018. Retrieved 20 October 2018.
  17. ^ "Qualys SSL Labs - SSL Pulse". www.ssllabs.com. 4 December 2022. Archived from the original on 7 December 2022. Retrieved 7 December 2022..
  18. ^ "TLS 1.3: Slow adoption of stronger web encryption is empowering the bad guys". Help Net Security. 6 April 2020. Archived from the original on 24 May 2022. Retrieved 23 May 2022.
  19. ^ Eckersley, Peter (17 June 2010). "Encrypt the Web with the HTTPS Everywhere Firefox Extension". EFF blog. Archived from the original on 25 November 2018. Retrieved 20 October 2018.
  20. ^ "HTTPS Everywhere". EFF projects. 7 October 2011. Archived from the original on 5 June 2011. Retrieved 20 October 2018.
  21. ^ "HTTPS-Only Mode in Firefox". Archived from the original on 12 November 2021. Retrieved 12 November 2021.
  22. ^ "Manage Chrome safety and security - Android - Google Chrome Help". support.google.com. Archived from the original on 7 March 2022. Retrieved 7 March 2022.
  23. ^ "Hands on Chrome's HTTPS-First Mode". Techdows. 19 July 2021. Archived from the original on 7 March 2022. Retrieved 7 March 2022.
  24. ^ Singel, Ryan (24 March 2010). "Law Enforcement Appliance Subverts SSL". Wired. Archived from the original on 17 January 2019. Retrieved 20 October 2018.
  25. ^ Schoen, Seth (24 March 2010). "New Research Suggests That Governments May Fake SSL Certificates". EFF. Archived from the original on 4 January 2016. Retrieved 20 October 2018.
  26. ^ a b Duncan, Robert (25 June 2013). "SSL: Intercepted today, decrypted tomorrow". Netcraft. Archived from the original on 6 October 2018. Retrieved 20 October 2018.
  27. ^ Cimpanu, Catalin (12 April 2016). "Let's Encrypt Launched Today, Currently Protects 3.8 Million Domains". Softpedia News. Archived from the original on 9 February 2019. Retrieved 20 October 2018.
  28. ^ Kerner, Sean Michael (18 November 2014). "Let's Encrypt Effort Aims to Improve Internet Security". eWeek.com. Quinstreet Enterprise. Archived from the original on 2 April 2023. Retrieved 20 October 2018.
  29. ^ Eckersley, Peter (18 November 2014). "Launching in 2015: A Certificate Authority to Encrypt the Entire Web". Electronic Frontier Foundation. Archived from the original on 18 November 2018. Retrieved 20 October 2018.
  30. ^ Qualys SSL Labs. "SSL Pulse". Archived from the original (3 February 2019) on 15 February 2019. Retrieved 25 February 2019.
  31. ^ "Qualys SSL Labs - SSL Pulse". www.ssllabs.com. Retrieved 4 September 2023.
  32. ^ "Mozilla Firefox Privacy Policy". Mozilla Foundation. 27 April 2009. Archived from the original on 18 October 2018. Retrieved 20 October 2018.
  33. ^ "Opera 8 launched on FTP". Softpedia. 19 April 2005. Archived from the original on 9 February 2019. Retrieved 20 October 2018.
  34. ^ Lawrence, Eric (31 January 2006). "HTTPS Security Improvements in Internet Explorer 7". Microsoft Docs. Archived from the original on 24 October 2021. Retrieved 24 October 2021.
  35. ^ Myers, Michael; Ankney, Rich; Malpani, Ambarish; Galperin, Slava; Adams, Carlisle (20 June 1999). "Online Certificate Status Protocol – OCSP". Internet Engineering Task Force. doi:10.17487/RFC2560. Archived from the original on 25 August 2011. Retrieved 20 October 2018. {{cite journal}}:저널 요구사항 인용 journal=(도움말)
  36. ^ "Baseline Requirements". CAB Forum. Archived from the original on 20 October 2014. Retrieved 1 November 2021.
  37. ^ Korzhitskii, Nikita; Carlsson, Niklas (2021). Revocation Statuses on the Internet. arXiv:2102.04288. {{cite book}}: work=무시됨(도움말)
  38. ^ "Manage client certificates on Chrome devices – Chrome for business and education Help". support.google.com. Archived from the original on 9 February 2019. Retrieved 20 October 2018.
  39. ^ Pusep, Stanislaw (31 July 2008). "The Pirate Bay un-SSL" (PDF). Archived (PDF) from the original on 20 June 2018. Retrieved 20 October 2018.
  40. ^ "SSL/TLS Strong Encryption: FAQ". apache.org. Archived from the original on 19 October 2018. Retrieved 20 October 2018.
  41. ^ Lawrence, Eric (22 October 2005). "Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2". Microsoft. Archived from the original on 20 September 2018. Retrieved 20 October 2018.
  42. ^ "Server Name Indication (SNI)". inside aebrahim's head. 21 February 2006. Archived from the original on 10 August 2018. Retrieved 20 October 2018.
  43. ^ Pierre, Julien (19 December 2001). "Browser support for TLS server name indication". Bugzilla. Mozilla Foundation. Archived from the original on 8 October 2018. Retrieved 20 October 2018.
  44. ^ "sslstrip 0.9". Archived from the original on 20 June 2018. Retrieved 20 October 2018.
  45. ^ Shuo Chen; Rui Wang; XiaoFeng Wang; Kehuan Zhang (20 May 2010). "Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow". Microsoft Research. IEEE Symposium on Security & Privacy 2010. Archived from the original on 22 July 2018. Retrieved 20 October 2018.
  46. ^ Guaay, Matthew (21 September 2017). "How to Force a Public Wi-Fi Network Login Page to Open". Archived from the original on 10 August 2018. Retrieved 20 October 2018.
  47. ^ "NeverSSL". Archived from the original on 1 September 2018. Retrieved 20 October 2018.
  48. ^ Walls, Colin (2005). Embedded Software: The Works. Newnes. p. 344. ISBN 0-7506-7954-9. Archived from the original on 9 February 2019. Retrieved 20 October 2018.
  49. ^ "A secure web is here to stay". Chromium Blog. Archived from the original on 24 April 2019. Retrieved 22 April 2019.

외부 링크

위키미디어 커먼즈에는 HTTPS와 관련된 미디어가 있습니다.
  • RFC 8446:IMT-2000 3GPP-TLS 프로토콜 버전 1.3