views:

464

answers:

8

Suppose I setup a simple php web server with a page that can be accessed by https. The url has simple parameters like https://www.example.com/test?abc=123. Is it true that the parameter here in this case will be safe from people sniffing the packets? And would this be true if the server does not employ any SSL certificate?

+5  A: 

depends on what you mean by safe

SSL encrypts the entire HTTP request/response, so the URL in the GET portion will be encrypted. This does not stop MITM attacks and corruption of the integrity of the SSL session itself. If a non-authoritative certificate is used, this makes potential attack vectors simpler.

http://stackoverflow.com/questions/73536/are-rest-request-headers-encrypted-by-ssl

Is a similar question.

Aiden Bell
+1  A: 

HTTPS Establishes an underlying SSL conenction before any HTTP data is transferred. This ensures that all URL data (with the exception of hostname, which is used to establish the connection) is carried solely within this encrypted connection and is protected from man-in-the-middle attacks in the same way that any HTTPS data is.

All HTTP-level transactions within an HTTPS connection are conducted within the established SSL session, and no query data is transferred before the secure connection is established.

From the outside the only data that is visible to the world it the hostname and port you are connecting to. Everything else is simply a stream of binary data which is enctypted using a private key shared only between you and the server.

In the example you provide your browser would do this:

  1. Derive hostname (and port if present) from from URL.
  2. Connect with to host.
  3. Check certificate (it must be 'signed' by known authority, apply specifically to correct IP address and port, and be current).
  4. The browser and server exchange cryptographic data and the browser receives a private key.
  5. The HTTP request is made, encrypted with established cryptography.
  6. HTTP response is received. Also encrypted.

HTTP is an 'Application Layer' protocol, it is carried on top of the secure layer. According the SSL specification, drawn up by Netscape, dictates that no application layer data may be transmitted until a secure connection is established - as outlined in the following paragraph:

"At this point, a change cipher spec message is sent by the client, and the client copies the pending Cipher Spec into the current Cipher Spec. The client then immediately sends the finished message under the new algorithms, keys, and secrets. In response, the server will send its own change cipher spec message, transfer the pending to the current Cipher Spec, and send its finished message under the new Cipher Spec. At this point, the handshake is complete and the client and server may begin to exchange application layer data." http://wp.netscape.com/eng/ssl3/draft302.txt

So yes. The data contained in the URL query on an HTTPS connection is encrypted. However it is very poor practice to include such sensitive data as a password in the a 'GET' request. While it cannot be intercepted, the data would be logged in plaintext serverlogs on the receiving HTTPS server, and quite possibly also in browser history. It is probably also available to browser plugins and possibly even other applications on the client computer. At most an HTTPS URL could be reasonably allowed to include a session ID or similar non-reusable variable. It should NEVER contain static authentication tokens.

The HTTP connection concept is most clearly explained here: http://www.ourshop.com/resources/ssl_step1.html

Ray Hayes
+5  A: 

The requested URI (/test?abc=123) is sent to the web server as part of the HTTP request header and thus encrypted.

However URLs can leak in other ways, usually web browser toolbars, bookmarks, and sending links to friends. POSTing data may be more appropriate depending on the context/sensitivity of the data you're sending.

I believe an HTTPS connection requires an SSL certificate, even a self-generated one if you don't want to buy one.

Hope that helps a bit!

+1  A: 

The url:s will be stored both in the server logs and in the browser history so even if they aren't sniffable they are far from safe.

idstam
+4  A: 

Yes your URL would be safe from sniffing; however, one hole that is easily overlooken is if your page references any third party resources such as Google Analytics, Add Content anything, your entire URL will be sent to the third party in the referer. If its really sensitive it doesn't belong in the query string.

As for your second part of the question, you can't use SSL if you don't have a certificate on the server.

JoshBerke
Why a downvote? Your URL is sent to as a referer to retrieve all your linked content.
JoshBerke
Excellent point, Josh. +1.
erickson
A: 

On the wire, yes. At the end points (browser and server) not necessarily. SSL/TLS is transport layer security. It will encrypt your traffic between the browser and the server. It is possible on the browser-side to peek at the data (a BHO for example). Once it reaches the server-side, it is available to the recipient of course and is only as secure as he treats it. If the data needs to move securely beyond the initial exchange and protected from prying eyes on the client, you should also look at message layer security.

JP Alioto
A: 

The SSL/TSL is a Transport Layer Security, yes the data can be picked with BHO (as @JP wrote) or any add on but also with "out of browser" HTTP sniffers. They read messaging between winsock32 and the application. The encryption takes place in the winsock32 not in the browser.

Take a look (this part was taked from the page of IEinspector): IEInspector HTTP Analyzer is such a handy tool that allows you to monitor, trace, debug and analyze HTTP/HTTPS traffic in real-time.

backslash17
A: 

So let me get this straight, if the HTTPS request is in the request header. How do the inbetween routers know the destination address. I would assume that they they know the source and destination IP, but not the URI portion?