HTTPS URL이 암호화됩니까?

HTTPS URL이 암호화됩니까?

---

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

요약

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

2019 년 3 월 업데이트

이 문제 를 제기 해주신 carlin.scott 에게 감사드립니다 .

The payload in the SNI extension can now be encrypted via this draft RFC proposal. This capability only exists in TLS 1.3 (as an option and it's up to both ends to implement it) and there is no backwards compatibility with TLS 1.2 and below.

CloudFlare is doing it and you can read more about the internals here — If the chicken must come before the egg, where do you put the chicken?

In practice this means that instead of transmitting the FQDN in plain text (like the Wireshark capture shows), it is now encrypted.

NOTE: This addresses the privacy aspect more than the security one since a reverse DNS lookup MAY reveal the intended destination host anyway.

---

As the other answers have already pointed out, https "URLs" are indeed encrypted. However, your DNS request/response when resolving the domain name is probably not, and of course, if you were using a browser, your URLs might be recorded too.

---

Entire request and response is encrypted, including URL.

Note that when you use a HTTP Proxy, it knows the address (domain) of the target server, but doesn't know the requested path on this server (i.e. request and response are always encrypted).

---

I agree with the previous answers:

To be explicit:

With TLS, the first part of the URL (https://www.example.com/) is still visible as it builds the connection. The second part (/herearemygetparameters/1/2/3/4) is protected by TLS.

However there are a number of reasons why you should not put parameters in the GET request.

First, as already mentioned by others: - leakage through browser address bar - leakage through history

In addition to that you have leakage of URL through the http referer: user sees site A on TLS, then clicks a link to site B. If both sites are on TLS, the request to site B will contain the full URL from site A in the referer parameter of the request. And admin from site B can retrieve it from the log files of server B.)

---

An addition to the helpful answer from Marc Novakowski - the URL is stored in the logs on the server (e.g., in /etc/httpd/logs/ssl_access_log), so if you don't want the server to maintain the information over the longer term, don't put it in the URL.

---

Yes and no.

The server address portion is NOT encrypted since it is used to set up the connection.

This may change in future with encrypted SNI and DNS but as of 2018 both technologies are not commonly in use.

The path, query string etc. are encrypted.

Note for GET requests the user will still be able to cut and paste the URL out of the location bar, and you will probably not want to put confidential information in there that can be seen by anyone looking at the screen.

---

A third-party that is monitoring traffic may also be able to determine the page visited by examining your traffic an comparing it with the traffic another user has when visiting the site. For example if there were 2 pages only on a site, one much larger than the other, then comparison of the size of the data transfer would tell which page you visited. There are ways this could be hidden from the third-party but they're not normal server or browser behaviour. See for example this paper from SciRate, https://scirate.com/arxiv/1403.0297.

In general other answers are correct, practically though this paper shows that pages visited (ie URL) can be determined quite effectively.

---

You can not always count on privacy of the full URL either. For instance, as is sometimes the case on enterprise networks, supplied devices like your company PC are configured with an extra "trusted" root certificate so that your browser can quietly trust a proxy (man-in-the-middle) inspection of https traffic. This means that the full URL is exposed for inspection. This is usually saved to a log.

Furthermore, your passwords are also exposed and probably logged and this is another reason to use one time passwords or to change your passwords frequently.

Finally, the request and response content is also exposed if not otherwise encrypted.

One example of the inspection setup is described by Checkpoint here. An old style "internet café" using supplied PC's may also be set up this way.

---

Linking to my answer on a duplicate question. Not only is the URL available in the browsers history, the server side logs but it's also sent as the HTTP Referer header which if you use third party content, exposes the URL to sources outside your control.

---

It is now 2019 and the TLS v1.3 has been released. According to Cloudflare, the SNI can be encrypted thanks to TLS v1.3. So, I told myself great! let's see how it looks within the TCP packets of cloudflare.com So, I caught a "client hello" handshake packet from a response of the cloudflare server using Google Chrome as browser & wireshark as packet sniffer. I still can read the server name in plain text within the Client hello packet.

So, beware of what you can read because this is still not an anonymous connection since an intermediary can see the target server name.

So it looks like the encryption of the SNI requires additional implementations to work along with TLSv1.3

The following article describes the encryption of the SNI provided by Cloudflare as part of TLSv1.3. However, all the HTTPs URLs from cloudflare.com are in plain text within the TCP packet under TLS v1.3

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

---

Althought there are some good answers already here, most of them are focusing in browser navigation. I'm writing this in 2018 and probably someone wants to know about the security of mobile apps.

For mobile apps, if you control both ends of the application (server and app), as long as you use HTTPS you're secure. iOS or Android will verify the certificate and mitigate possible MiM attacks (that would be the only weak point in all this). You can send sensitive data through HTTPS connections that it will be encrypted during transport. Just your app and the server will know any parameters sent through https.

The only "maybe" here would be if client or server are infected with malicious software that can see the data before it is wrapped in https. But if someone is infected with this kind of software, they will have access to the data, no matter what you use to transport it.

---

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

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

참고 URL : https://stackoverflow.com/questions/499591/are-https-urls-encrypted