Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am building a personal server. I want to be able to access this server from anywhere, and I don't want this server to get blocked. It is my understanding that HTTPS encrypts my traffic, but I also heard that it doesn't completely encrypt it. I heard that if you go to a website with a domain, a DNS look-up is performed without encryption, and therefore an ISP could figure out which domain my personal server is on (and what it's IP is). But what if I accessed my server from it's IP address?

Question: If I access a server by going to it's IP address, and I use HTTPS (so the URL would be something like https://###.###.###.###/), is it possible for anyone (including ISPs and people "behind the same router as me") to figure out the IP address of the server I'm accessing? If so, should I use SSL1/SSL2/SSL3 or should I use TLS1/TLS1.1/TLS1.2 or does it not matter?

By the way, the server's certificate will be self-signed, and this server will only be accessed on port 443 (HTTPS).

share|improve this question

closed as not a real question by Shane Madden, Michael Hampton, Ward, mailq, Scott Pack Oct 2 '12 at 18:28

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

    
en.wikipedia.org/wiki/OSI_model Note the relative positions of IP, TCP and SSL. If you think in terms of envelopes, the innermost envelope is SSL. Outside of that is the TCP one, which will specify things like the port number, the sequence number, etc. The outermost one is the IP envelope, which will have the IP address. Note that TCP and IP cannot be encrypted, otherwise the envelope containing the SSL payload will not get delivered. We won't get into proxies and VPNs here. –  cjc Aug 13 '12 at 18:05
3  
A simple analogy. How would the phone company be able to connect a call from you if you encoded the phone number with some random coding system that you made up? –  Zoredache Aug 13 '12 at 19:59
add comment

3 Answers

up vote 9 down vote accepted

Answer: yes. Your browser will still promptly engage in the three-way TCP handshake with the server at ###.###.###.###, and your ISP can see that. Once the connection's set up, your browser will have an SSL handshake with the server, and your ISP can see that. Once session keys have been negotiated, your browser will continue to exchange SSL-encrypted packets with the server, and your ISP can see them. It can't see what's in them, but the source and destination address are - and have to remain - unencrypted.

If you want to browse that privately, look into privoxy + TOR.

share|improve this answer
    
Both of which expose the ip address till you hit the proxy server or TOR node. –  Fiasco Labs Aug 11 '13 at 7:36
    
That is true, but they don't expose the IP address of the server you're requesting content from, which is what the OP asked to protect him/herself from. –  MadHatter Aug 24 '13 at 5:57
add comment

Yes, this is entirely possible and in fact required for any traffic to reach your server.

share|improve this answer
add comment

"Encrypt the IP" is technically nonsense. An SSL-encrypted https TCP stream is still a TCP stream, and the connection cannot be made without IP addresses. Everyone in the position to observe the traffic can easily log the source IP, source port, destination IP, destination port, and bytes sent in each direction. What gets logged and for how long depends on who's watching, and whether they are compromised or acting under a subpeona.

Assuming you are connecting to a WiFi access point which in turn is connected to an ISP which is routing your traffic across the backbone to your hosting ISP which is providing a virtual or co-located host, this boils down to:

  • Your WiFi router (and everyone also attached to it) can see:
    • Your MAC address, which identifies your physical hardware uniquely.
    • Your server's IP, port, and how much traffic you exchanged with it.
  • Your router's ISP (and the network backbone) can see:
    • Your router's public IP. If this is a US residential connection, they likely log the public IP and the account holder and maintain those records for 6 months.
    • Your server's IP, port, and how much traffic you exchanged with it.
  • Your hosting company (who likely knows who you are) can see:
    • Your router's public IP, port, and how much traffic you exchanged with your server.

If you want to hide your connection to it, use Tor, as mentioned by MadHatter. Everyone up to (and including) the Tor entry node can know you're using Tor, but not what you are connecting to. Everyone after (and including) the Tor exit node will know that a Tor user connected to your server, but not who.

Under normal circumstances, there is some danger in a compromised exit node logging or modifying the contents of your session, but that is mostly mitigated using SSL.

If you want to further hide your server, set it up as a Tor hidden service. In this case there is no Tor exit node, and it may require shell access to your server to even identify that it is running a web service, particularly if you also configure it as a Tor relay to mask the traffic. You will then need to access it as https://blahblah.onion, so your PC wouldn't even know the IP from your web access.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.