TLS / SSL (HTTPS) 암호화를 사용할 때 모든 URL이 암호화됩니까? TLS / SSL (HTTPS)을 사용할 때 모든 URL 데이터를 숨기고 싶어서 알고 싶습니다.

TLS / SSL이 전체 URL 암호화를 제공하는 경우 URL에서 기밀 정보를 숨길 염려가 없습니다.

예, SSL 연결은 TCP 계층과 HTTP 계층 사이에 있습니다. 클라이언트와 서버는 먼저 SSL / TLS 프로토콜을 통해 안전한 암호화 된 TCP 연결을 설정 한 다음 암호화 된 TCP 연결을 통해 HTTP 요청 (GET, POST, DELETE ...)을 보냅니다.

아무도 와이어 캡처를 제공하지 않았으므로 여기에 있습니다.
서버 이름 (URL의 도메인 부분)은 ClientHello패킷에 일반 텍스트로 표시 됩니다.

다음은 브라우저 요청을 보여줍니다.
https://i.stack.imgur.com/path/?some=parameters&go=here

TLS 버전 필드에 대한 자세한 내용은이 답변 을 참조하십시오 (버전이 아닌 각 버전 번호가있는 필드가 아닌 3 개가 있습니다!)

에서 https://www.ietf.org/rfc/rfc3546.txt :

3.1. 서버 이름 표시

[TLS]는 클라이언트가 서버에 접속중인 서버 이름을 알려주는 메커니즘을 제공하지 않습니다. 클라이언트가 단일 기본 네트워크 주소에서 여러 '가상'서버를 호스팅하는 서버에 대한 보안 연결을 용이하게하기 위해이 정보를 제공하는 것이 바람직 할 수 있습니다.

서버 이름을 제공하기 위해 클라이언트는 (확장 된) 클라이언트 hello에 "server_name"유형의 확장명을 포함 할 수 있습니다.

한마디로 :

• FQDN (URL의 도메인 부분은) 수도 전송 될 명확에서 내부 ClientHelloSNI 확장을 사용하는 경우 패킷

• 요청 URL이 HTTP (OSI Layer 7)이므로 나머지 URL ( /path/?some=parameters&go=here)은 내부에 비즈니스가 ClientHello없으므로 TLS 핸드 셰이크 (계층 4 또는 5)에 표시되지 않습니다. 즉,의에 나중에 올 것이다 GET /path/?some=parameters&go=here HTTP/1.1, HTTP 요청 후에 보안 TLS 채널이 설정됩니다.

행정상 개요

도메인 이름은 명확하게 전송 될 수 있지만 (TLS 핸드 셰이크에서 SNI 확장이 사용되는 경우) URL (경로 및 매개 변수)은 항상 암호화됩니다.

2019 년 3 월 업데이트

이것을 가져 주셔서 감사합니다 carlin.scott .

SNI 확장의 페이로드는 이제이 초안 RFC 제안을 통해 암호화 될 수 있습니다 . 이 기능은 TLS 1.3에만 존재하며 (옵션으로 구현할 수 있으며, TLS 1.2 이하 버전과의 호환성은 없습니다.)

CloudFlare가이 작업을 수행하고 있으며 내부에 대한 자세한 내용은 여기를 참조하십시오 . 닭고기가 계란보다 먼저 와야하는 경우 닭고기를 어디에 두어야합니까?

실제로 이것은 Wireshark 캡처 ​​쇼와 같이 FQDN을 일반 텍스트로 전송하는 대신 이제 암호화되어 있음을 의미합니다.

참고 : 이 방법은 역방향 DNS 조회가 의도 한 대상 호스트를 나타낼 수 있으므로 보안 측면보다 개인 정보 측면을 해결합니다.

는 AS 다른 답변을 이미 지적, HTTPS "URL은"실제로 암호화됩니다. 그러나 도메인 이름을 확인할 때 DNS 요청 / 응답이 아닐 수 있으며 브라우저를 사용하는 경우 URL도 기록 될 수 있습니다.

URL을 포함한 전체 요청 및 응답이 암호화됩니다.

HTTP 프록시를 사용할 때 대상 서버의 주소 (도메인)는 알고 있지만이 서버에서 요청 된 경로는 알 수 없습니다 (예 : 요청 및 응답은 항상 암호화 됨).

이전 답변에 동의합니다.

명시 적으로 :

TLS를 사용 하면 연결을 구축 할 때 URL의 첫 번째 부분 ( https://www.example.com/ )이 계속 표시됩니다. 두 번째 부분 (/ herearemygetparameters / 1 / 2 / 3 / 4)은 TLS로 보호됩니다.

그러나 GET 요청에 매개 변수를 넣지 말아야하는 이유는 여러 가지가 있습니다.

첫째, 다른 사람들이 이미 언급했듯이 :-브라우저 주소 표시 줄을 통한 누출-기록을 통한 누출

또한 http referer를 통해 URL이 유출 된 경우 : 사용자가 TLS에서 사이트 A를 본 다음 사이트 B 로의 링크를 클릭합니다. 두 사이트가 모두 TLS에 있으면 사이트 B에 대한 요청은 요청의 referer 매개 변수 그리고 사이트 B의 관리자는 서버 B의 로그 파일에서 검색 할 수 있습니다.)

Marc Novakowski의 유용한 답변 외에도 URL은 서버의 로그 (예 : / etc / httpd / logs / ssl_access_log)에 저장되므로 서버에서 더 이상 정보를 유지하지 않으려면 용어는 URL에 넣지 마십시오.

예, 아니오

서버 주소 부분은 연결 설정에 사용되므로 암호화되지 않습니다.

향후 암호화 된 SNI 및 DNS로 변경 될 수 있지만 2018 년 현재 두 기술은 일반적으로 사용되지 않습니다.

경로, 쿼리 문자열 등이 암호화됩니다.

GET 요청의 경우 사용자는 여전히 위치 표시 줄에서 URL을 잘라내어 붙여 넣을 수 있으며 화면을 보는 사람이 볼 수있는 기밀 정보를 입력하지 않을 것입니다.

트래픽을 모니터링하는 타사는 트래픽을 사이트를 방문 할 때 다른 사용자가 가진 트래픽과 비교하여 트래픽을 검사하여 방문한 페이지를 확인할 수도 있습니다. 예를 들어, 사이트에 두 페이지 만 있고 한 페이지는 다른 페이지보다 훨씬 큰 경우 데이터 전송 크기를 비교하면 방문한 페이지를 알 수 있습니다. 타사에서이를 숨길 수있는 방법이 있지만 일반적인 서버 나 브라우저 동작은 아닙니다. 예를 들어 SciRate ( https://scirate.com/arxiv/1403.0297) 의이 백서를 참조하십시오 .

실제로이 백서에서는 방문한 페이지 (예 : URL)를 매우 효과적으로 결정할 수 있음을 보여 주지만 다른 대답은 정확합니다.

전체 URL의 개인 정보 보호를 항상 신뢰할 수있는 것은 아닙니다. 예를 들어, 엔터프라이즈 네트워크의 경우와 같이 회사 PC와 같은 제공된 장치는 추가 "신뢰할 수있는"루트 인증서로 구성되어 브라우저가 https 트래픽의 프록시 (중간자) 검사를 조용히 신뢰할 수 있습니다. . 이는 전체 URL이 검사를 위해 노출됨을 의미합니다. 이것은 일반적으로 로그에 저장됩니다.

또한 암호도 노출되어 기록 될 수 있으므로 한 번만 암호 를 사용 하거나 암호를 자주 변경 해야하는 또 다른 이유 입니다.

마지막으로, 요청 및 응답 컨텐츠는 달리 암호화되지 않은 경우 노출됩니다.

검사 설정의 한 예는 여기 Checkpoint에 설명되어 있습니다 . 제공된 PC를 사용하는 구식 "인터넷 카페"도이 방법으로 설정할 수 있습니다.

중복 질문 에 대한 답변과 연결합니다 . 브라우저 기록, 서버 측 로그에서 URL을 사용할 수있을뿐만 아니라 HTTP 참조 헤더로도 전송되어 타사 컨텐츠를 사용하는 경우 URL을 제어 할 수없는 소스에 노출합니다.

이제 2019 년이며 TLS v1.3이 릴리스되었습니다. Cloudflare에 따르면 SNI는 TLS v1.3 덕분에 암호화 될 수 있습니다. 그래서 나는 나 자신에게 위대하다고 말했다! cloudflare.com의 TCP 패킷 내에서 어떻게 보이는지 보도록하겠습니다. 따라서 브라우저로 wirechrome을 사용하고 패킷 스니퍼로 wireshark를 사용하는 cloudflare 서버의 응답에서 "client hello"핸드 셰이크 패킷을 포착했습니다. 여전히 클라이언트 hello 패킷 내에서 서버 이름을 일반 텍스트로 읽을 수 있습니다.

따라서 익명 연결이 아니므로 읽을 수있는 내용에주의하십시오. 클라이언트와 서버 사이의 미들웨어는 클라이언트가 요청한 모든 도메인을 기록 할 수 있습니다.

따라서 SNI의 암호화는 TLSv1.3과 함께 작동하기 위해 추가 구현이 필요합니다.

다음 기사에서는 Cloudflare가 TLSv1.3의 일부로 제공 한 SNI의 암호화에 대해 설명합니다. 그러나 cloudflare.com의 모든 HTTP URL은 TLS v1.3의 TCP 패킷 내에 일반 텍스트로 표시됩니다.

[ https://blog.cloudflare.com/encrypted-sni/][3]

예, 아니오

실제 URL은 암호화되어 있으므로 누군가가 방문한 웹 사이트의 정확한 웹 페이지를 알 수 없습니다. 그러나 TLS 헤더에는 액세스중인 서버의 호스트 이름 (예 : www.quora.com)이 암호화되지 않습니다. DNS도 거의 암호화되지 않으며 액세스중인 호스트 이름도 유출됩니다. 이 DNS 쿼리는 기본적으로 ISP의 서버에 거의 항상 영향을 미치므로 DNS 요청을 다른 DNS 서버로 스니핑하거나 자신의 URL을 기록하여 액세스하는 모든 웹 사이트의 호스트 이름을 쉽게 볼 수 있습니다.

그러나 귀하의 우려가 누군가가 귀하가 액세스하는 웹 사이트를 찾을 수 있는지 여부라면 충분하지 않습니다. HTTPS는 OSI Layer 4에서 작동하며 해당 레벨의 모든 데이터를 암호화하지만 하위 레벨은이를 전달하는 네트워크에 맡겨집니다. 누군가는 여전히 OSI 계층 3에서 트래픽의 경로와 대상을 추적 할 수 있습니다. 이는 트래픽을 스니핑하는 누군가가 IP 주소를 찾고, 확장하여 액세스 한 웹 사이트의 도메인 이름을 찾을 수 있음을 의미합니다.

더 나쁜 것은, 처음 (그리고 DNS 캐시가 지워지는 방법 / 시간에 따라 몇 번의 후속 시간)에는 DNS 서버가 HTTPS 대상 URL의 IP 주소를 요청하는 모든 대상에게 암호화되지 않은 DNS 쿼리를 보낼 것입니다. 일반적으로 ISP 서버) 기본적으로 DNS 서버 경로를 따라 트래픽에 액세스 할 수있는 사용자는이 쿼리를 스니핑 할 수 있습니다.

높은 수준의 프라이버시를 찾고 있다면 신뢰할 수있는 암호화 된 VPN 및 / 또는 암호화 된 프록시 서비스로 HTTPS를 보완해야합니다. DNSSEC를 조사하여 DNS 쿼리를 보호 할 수도 있습니다. 이 서비스는 트래픽의 소스 및 대상을 쉽게 추적 할 수 있으므로 신뢰할 수 있어야합니다.

여기에 이미 좋은 답변이 있지만 대부분 브라우저 탐색에 중점을두고 있습니다. 2018 년에 이것을 작성하고 있으며 누군가가 모바일 앱의 보안에 대해 알고 싶어 할 것입니다.

모바일 앱 의 경우 HTTPS 를 사용하는 한 애플리케이션 (서버 및 앱)의 양쪽 끝을 제어하는 ​​경우 안전 합니다. iOS 또는 Android는 인증서를 확인하고 가능한 MiM 공격을 완화합니다 (이 모든 것의 유일한 약점). 전송 중에 암호화 될 HTTPS 연결을 통해 중요한 데이터를 보낼 수 있습니다 . 앱과 서버 만 https를 통해 전송 된 모든 매개 변수를 알 수 있습니다.

여기서 "아마도"는 클라이언트 나 서버가 데이터를 https에 싸기 전에 볼 수있는 악성 소프트웨어에 감염된 경우입니다. 그러나 누군가 이런 종류의 소프트웨어에 감염된 경우 전송하는 데 사용하는 데이터에 관계없이 데이터에 액세스 할 수 있습니다.

또한 ReSTful API를 구축하는 경우 클라이언트가 브라우저가 아니고 링크를 클릭하는 사용자가 없을 수 있으므로 브라우저 유출 및 http 참조 문제가 대부분 완화됩니다.

이 경우 베어러 토큰을 얻기 위해 oAuth2 로그인을 권장합니다. 어떤 경우에는 민감한 데이터 만 초기 자격 증명이 될 것입니다. 아마도 포스트 요청에 있어야합니다.

당신은 이미 매우 좋은 답변을 가지고 있지만, 나는이 웹 사이트에 대한 설명을 정말로 좋아합니다 : https://https.cio.gov/faq/#what-information-does-https-protect

간단히 말해 : HTTPS 숨기기 사용 :

• HTTP 메소드
• 검색어 매개 변수
• POST 본문 (있는 경우)
• 요청 헤더 (쿠키 포함)
• 상태 코드