I'm trying to educate myself a little more about web standards and protocols, and at the same time I'm involved in a little project on the same subject.

I have a question about something I came across in the Wikipedia article for HTTPS. In the third paragraph of the Overview, there's a part that talks about how HTTPS encrypts everything but the port numbers and the IP address of the server. I would assume the former, since doesn't HTTPS always communicate over port 443? But what about the second part? How exactly would that be exposed? How would an intruder get that information? If the IP address for the server is retrieved as part of the DNS process, wouldn't the URL also be visible?

Okay, I'm sure I have a very loose understanding of the stuff I was saying in that last paragraph. I'm happy to be set straight. But basically I'm looking for some source that states the elements that HTTPS doesn't encrypt, if anything.

It has to do with the network layers in which the IP and port number are contained in the TCP/IP protocol stack. In OSI parlance, HTTP operates at layer 7 (application layer) and SSL operates at layers 6 and 5 (presentation/session), with port numbers in the TCP header (layer 4/transport layer) and IP addresses in the IP header (layer 3 / network layer.)

The key thing to keep in mind is that encryption at the higher levels in the protocol stack can't do anything about the fields in the other protocol layers. If you're an apache server using SSL, you're just encrypting the layer 7 (HTTP) content and sending it down to the lower layers. TCP picks up the encrypted SSL data and adds the port number, IP picks up the TCP segment and adds the IP address, and then the data link layer (probably Ethernet) adds the physical address (e.g. Ethernet MAC address) and sends it across the wire. The other side does the same process in reverse, eventually getting to the IP layer, where the packet is directed to the correct IP address, the TCP layer, where the segment is sent to the correct port, and then up to SSL, where the decryption happens.

For the IPs and port numbers to be encrypted, the encryption would have to happen at a lower layer in the TCP stack.

That's the standard, but you can configure your HTTPS server to listen to some other port, much the same way you can configure an ssh server to listen on a port other than 22. Your client would have to know that, of course, and specify the correct port as part of the url.

Keep in mind the common port numbers you see (80, 443, 22, etc) only represent what port the server initially listens on. The client can send the initial request to port X, but tell the server to then respond to the client on port Y. Each protocol can handle this differently.

Add into the mix NAT, where the router will talk out to the server on port X, ask the server to respond on port Y, then internally coordinate with your machine to expect an answer on port Z. It does so by modifying the layer 3 and 4 parts, while leaving the higher layers alone.

Thanks guys. I've meant to learn more about this for years but never got around to it (because, well, I'm lazy ). All this talk about layers always started making my head spin, but I want to get into it now.

Do you have any more info on HTTPS and SSL, Tony? I'd like to read up. Wikipedia should be a good start, though...

The Wikipedia article on the OSI model does a pretty good job explaining the fundamental concepts and citing examples of protocols at each layer. If you want more on TCP/IP in detail, get your hands on a copy of TCP/IP Illustrated Volume 1 by W. Richard Stevens.

SSL and TLS have changed a lot over the years, and I haven't really kept up with those changes, but I learned everything I know about them from Rescorla's "SSL and TLS" way back in the day.

Depending on the level of depth you want, you can probably get 80-90% of the way there between Wikipedia and searching for keywords on Stack Exchange before you crack open either of these books, but for that last 10%, they're both good reads.

Thanks Tony!

Another way of looking at it, is that only the particular process (web server, IMAP server, database server) at the other end can decrypt any of the message. So all the information that's needed to get the message to that process -- i.e., the IP address and port -- must be sent unencrypted.

Peter