I understand that by connecting securely over SSH or HTTPS, the data that I transfer is cryptographically secure. However, can someone spying on my connection still determine the server I'm sending it to? If they can, what are the risks? What information can they get from it?
They can. In order to establish a secure HTTPS connection a handshake must happen between you, (the client, i.e. your browser or any other application) and the server. Any data sent within the handshake is not encrypted.
About the risks, it's a broad topic to discuss. The plain information that you are connecting to some public server (Facebook, Gmail, etc.) might be useless, but there might be situations when this information actually might be a leverage for the attacker. It depends on the concrete situation.
Yes. This is called "Traffic Analysis".
Broadly speaking, the useful information that can be obtained is who you're talking to, and when. So if you're ssh'ed into a server and the packets look like someone typing, it then looks like you're up and actively engaged in some activity with that server. The volume of the data going back and forth can be enlightening as well.
Traffic analysis is widely used by Law Enforcement and spying organizations. For example, it was used to obtain search warrants on a Lulzsec hacker connected via TOR to anonymous chat forums. The content of the message can't be obtained, but the fact that traffic is going back and forth at the same times as a confidential informant is talking to a known anonymous hacker can be enough to obtain search warrants, or further investigations.
Sure, they can. A proper encryption is supposed only to hide the content, but is not expected to hide:
- parties involved in the communication
- size of data exchanged
- timing of packets
- (anything else)
Moreover, some data may be leaked from the initial handshake. For example, HTTPS with SNI leaks the domain you are connecting to in plaintext even if the adversary can't see your DNS traffic. This is usually a minor additional leak. (Note that there are some arguments that SNI does not usually make the situation worse, it just makes the problem more visible.)
Asking about risks (and mitigations) of disclosing the server you are connection to is a too broad question there. It mainly depends on what you consider to be secret. BTW, other potential leaks (e.g. data size and packet timing) seems to be more interesting.
HTTPS (relying on
TLS) use encryption, but are based on an established TCP/IP existing connection. This means that even if the content is opaque, all TCP/IP information are in clear and available to someone sniffing your network.
TCP/IP information includes IP address of each peer, port numbers used. This gives a good hint about protocol and kind of traffic.
Some information may also be exchanged during the handshake, giving out some information. For example, if SNI is used (when multiple HTTPS web servers share the same IP), the name of the website is part of the TLS handshake and could be available.
As a side note, even being blind about the content can giveaway information. I know about attacks on interactive SSH sessions that measure the time between keys typed to deduce the commands executed, the typing habits of the person, and even what keys were pressed.
It depends entirely on the topology of the network used to connect your computer to the server.
If your computer is connected to the server directly using an ethernet cable or similar connection, and those computers and cable are inside a secure room and you have made sure that nobody saw you entering the room then NO, nobody can know you have connected to that server.
But if you go through a network involving third parties, like the internet, then some members of those parties need to know who are you sending your encrypted data to. How would they know where to send it otherwise? So, yes, your Internet Service Provider can know where you are sending data. And so can any agency with legal or illegal power over your ISP. That is true for HTTPS, SSH and each and every kind of protocol, encrypted or not.
One way to avoid that is to use a third party which you can trust not to leak that information. Like the TOR network. Or a VPN.
There are several technologies involved in creating a secure connection (the network protocol stack). Each layer solves its own part of the job to make connections work. The parts of the stack that are relevant to your questions are:
HTTPS TCP IP
You can notice that HTTPS sits on top of TCP, which works on top of IP. HTTPS cannot change how underlying protocols work, thus encryption is added only to itself (and on protocol that works on top of HTTPS if any). IP packet header contains IP address of the host you are connecting to and TCP packet header contain port. So, unless underlying TCP and IP data is not embedded itself into some sort of encrypted channel (VPN, for example), whoever captures your network traffic in transit would be able to figure out target host/port.