HTTPS Response body - Is it secured?

Question

Would like to understand whether the HTTPS body part of the Response is encrypted. Also, in a HTTPS request whether the header are transmitted as plain text / encrypted?

Is there any tool with which I can observe the raw HTTPS traffic without decrypting it.

Answer 1

Anything sent over https is encrypted using SSL transport

Try WireShark or Fiddler as helpful tools for this.

Answer 2

HTTPS is HTTP over SSL. So the whole HTTP communication is encrypted.

Answer 3

When using HTTPS, the entire content of the request and reply are encrypted, including the headers and body. The HTTP protocol in plaintext happens on top of, TLS or SSL, so what's on the wire is encrypted.

Answer 4

YES https flow is encrypted. When an https connection is initialized, it uses a strong encryption algorithm to handshake and agree with other part on a less strong, but much faster encryption algorithm for the flow.

To observe network packets, you can use sniffers like http://www.ethereal.com/.

Answer 5

The entire HTTP session is encrypted including both the header and the body.

Any packet sniffer should be able to show you the raw traffic, but it'll just look like random bytes to someone without a deep understanding of SSL, and even then you won't get beyond seeing the key exchange as a third party.

Answer 6

Any packet capture/sniffing tool can show you the raw HTTPS traffic. To view the actual contents (by decrypting it), use Fiddler.

Answer 7

As the other posts say - HTTPS is HTTP (plaintext) wrapped in SSL on top of the TCP/IP layer. Every part of the HTTP message is encrypted. So the stack looks like:

TCP/IP

---

SSL

---

HTTP

As far as encryption goes, there is no way to see any part of the HTTP message with SSL around it.

If you need to debug your traffic I suggest the following:

• Use a network traffic watcher (like Ethereal) to watch the creation of connections. This will let you see the connection be initiated. It will show you the start of the SSL Handshake, details on failures, and when the session is set up, there will be chains of cipher text. The ciphertext is not very useful, but its presence lets you know data is going back and forth.
• Deubg your http layer in the clear prior to setting up HTTPS. Every application or web server I've ever worked with has let me turn off HTTPS, and host the same set of URLs in the clear. Do this, and watch it with the same network tool.
• If you get both sides talking with HTTP and everything breaks on HTTPS, it's time to look at either the SSL session establishment or anything in between the two points that may be interrupting the flow.