Is HTTPS as secure or more secure than SSH if both have an IP address whitelist?

Question

I'm wondering whether an HTTPS API endpoint would be as secure as or more secure than SSH.

API Endpoint

• The API endpoint would require HTTPS
• The API authentication would use a POST'd API key.
• The minimum required length of the API key could basically be arbitrarily long
• The API endpoint would only accept connections from whitelisted IP addresses.
• The API endpoint's URL would not be publicly available or linked from anywhere. Only the client application would know what it was.
• The client application connecting to the endpoint will not accept weak SSL cyphers.

SSH Connection

For the purposes of this question, we'll make the following assumptions about the SSH connection that we're comparing to.

• The minimum required password length is 8 characters with upper case, lower case, and number required.
• The domain that you connect to is the public facing domain (i.e. for http://domain.com you connect using ssh domain.com)

Considerations

Some considerations that I've thought of which may affect whether or not one is more secure than the other are:

• Is HTTPS's detection of IP address as reliable as how SSH does it? I'm guessing both of them just look at what the client sends them and therefore can't be 100% trusted, but nevertheless provide some level of security.
• I believe that SSH has a built in mechanism to prevent rapid retry attempts. I know that HTTPS by itself doesn't do that, but in many cases where security is paramount that it built into the web serve layer.

My hunch

My hunch would be that the API endpoint would actually be more secure than SSH for the following reasons - but I'm not a security expert by any stretch, so I'd love to get a solid answer:

• With SSH, the potential attacker knows what domain to target (i.e. ssh domain.com). But with the API, the URL would not be known so in order to even begin to try to attack it, they'd first have to figure out what the URL was.
• The API password strength is greater

Context

The reason I'm asking this is that I'm considering building an API endpoint that would allow a trusted, authenticated user to access a lot of potentially sensitive data. It would be a powerful tool that would allow for nicely decoupled application business logic to be written very quickly.

The reason why I'm asking whether it's as secure as SSH is because my assumption is that potential users for this application have SSH enabled with at most an IP address whitelist as an additional layer of security.

So that is to say that the capabilities of this API endpoint are already present via SSH. If the endpoint would present no additional risk over and above the risk that is present with SSH, then I would consider that an acceptable level of risk. But if it were less secure, then I would most likely not consider it acceptable.

UPDATE: Added note about weak cyphers to API endpoint.

Answer 1

Is HTTPS's detection of IP address as reliable as how SSH does it?

Both are protocols over TCP, where you verify the IP address when the TCP handshake is completed. (With a completely fake IP address the packets likely would not be routed to you, so you couldn't complete the TCP handshake (or more accurately have a 1 in 4 billion chance of guessing it) which requires replying back with a random 32-bit sequence number that the server directed to you). A powerful adversary who has control over a server on the network between the client and server can fake your IP address and collect and not forward packets intended for a faked IP address, but it requires them to have full control of a server on the actual route chosen through the network.

I believe that SSH has a built in mechanism to prevent rapid retry attempts

It doesn't really, you really need to setup fail2ban to do this. (Yes there are some options to insert delays within repeated password attempts within a ssh session, but they aren't that great).

---

I still don't understand the setup. Both SSH and HTTPS encompass a wide variety of setups. E.g., using self-signed HTTPS connection where you do no checking of untrusted certificates will be vulnerable to man in the middle attacks (at least with SSH it warns very loudly when host certificates change). Similarly there are some weak HTTPS protocols -- you shouldn't use SSLv2 or weak ciphers.

Is the HTTPS/SSH connection using a client certificates? Isn't this supposed to be automated?

If you have an API that needs to be run from a webserver, doing this securely with HTTPS is the natural route. SSH is intended for remotely connecting to another computers commandline. Yes, you can use it for other things like remote-command execution or tunneling network traffic, but if you want to offer a secure web-based API it makes much more sense to use TLS with checking client and server certificates (even if they are self-signed).

Answer 2

I will attempt to offer some pointers/counterpointers:

The API endpoint would require HTTPS

Which can be MITM'd if your network is not secure. I think you need to look at the network design before the application/presentation layer.

The API authentication would use a POST'd API key. The minimum required length of the API key could basically be arbitrarily long

If your network isn't secure, an API key could be sniffed, modified, etc., so if you create say a 200 char key, what good is it, if it is visible in clear text because your network is vulnerable?

The API endpoint would only accept connections from whitelisted IP addresses.

Whitelisting/blacklisting doesn't work since attackers can force triggers to get whitelisted addresses blacklisted. I will elaborate on this with your fail2ban comment.

The API endpoint's URL would not be publicly available or linked from anywhere. Only the client application would know what it was.

Now all you need to worry about is ensuring your client application is not on a vulnerable machine.

The minimum required password length is 8 characters with upper case, lower case, and number required.

SSH isn't the "end all" security solution where, just because you're running it, you won't be attacked, and or compromised. Strong passwords while helpful, will do little against a user whose machine is infected with a keystroke logger rendering any password useless.

Is HTTPS's detection of IP address as reliable as how SSH does it? I'm guessing both of them just look at what the client sends them and therefore can't be 100% trusted

An IP is an IP is an IP ad nauseam. The lookup occurs on the network level, and it's there you want to shift your focus to. So without going line by line:

In a fail2ban scenario: What you're doing here is saying: "Look, go into my log files, see if anything suspect is going on, if so, then you need to add offenders address to a blacklist because I want to stop him."

Scenario: "As an attacker, I generate noise using netcat. I scan your server using the spoofed address of 0.0.0.0 you now block the world. As same attacker, I pre-generate packets scanning you as your default route... Your business partner I gleaned from press releases on your site... Random addresses." These are now all blocked. Not to mention, the more rules you have on your firewall, the longer it takes to process packets. To understand this more, read "Failed2Ban"

Your BEST bet is to create BLOCK ALL and ALLOW IN SPECIFICS this way you don't have to worry about randoms (spoofed addresses, etc.)

On the instance you described, you are trying to perform tasks which should be on the network layer, you're trying to get a different layer responsibilities to address the flaws. It won't work.

If it were me on the design side of the equation, I'd aim at a VPN based connection if possible.

Client --> send data --> only using a tunnel --> server
Connection established/made --> decrypt data from the tunnel, give it to the right application

In this instance (IPSEC VPN tunnel) you have a bit more protection from replay attacks (if using AH), so its more difficult to MITM than attacks on SSL. With SSL, you add the overhead for "certificate errors" (that most people will ignore, etc).

Which makes me ask, this connection is it for dedicated clients, the world, etc., I ask because this kind of setup (VPN tunnels) won't work for dynamic connections. E.g., you gain a new random client who signed up, you now need a tunnel * 100,000 new clients, versus you creating 24 tunnels for dedicated clients.

A lot of thought need be placed on your scenario, but for the most part, this is what came to mind reading your question.