2

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.

  • I wrote a question earlier today to address this issue but I didn't quite frame the question properly and it was too subjective. Through the process of getting feedback, I realized that the root of my question boils down to this question which is much more clear cut and objective. security.stackexchange.com/questions/58094/… – kalenjordan May 16 '14 at 3:50
5

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).

  • Thanks Jim Bob. When you say you don't understand the setup, could you flesh out that question a bit further? I'm basically considering using an HTTPS API to get at some sensitive data, and just want to know that this is as secure as SSH. – kalenjordan May 16 '14 at 15:01
  • If properly implemented both can be as secure. My point is saying HTTPS doesn't specify much. How does the client verify the server's identity in your HTTPS API (SSH does this well with host key checking as long as the initial connection wasn't attacked)? How does the server verify the clients identity? Are weak SSL ciphers blocked? – dr jimbob May 16 '14 at 16:46
  • okay this is exactly what I needed to get at - thanks super helpful. I'm going to need to look into what the implementation for this looks like, but yes I should be able to ensure that weak SSL ciphers are blocked. Since I'm not very familiar with security at the network level, I'm basically looking for a list of requirements that will make my HTTPS API as secure as or more secure than SSH. So basically I'm trying to define what "properly implemented" means exactly. – kalenjordan May 16 '14 at 16:57
  • It sounds like you're saying Yes, the HTTPS API is as secure or more secure than SSH, given that it's properly implemented - and now I'm just trying to define what exactly properly implemented means. If the bullet points I've listed under the API Endpoint section doesn't cover everything, then I need to figure out what I'm missing. Can't thank you enough for your help here! – kalenjordan May 16 '14 at 17:10
1

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.

  • +1 thanks @munkeyoto. Appreciate that context. So I fully understand and appreciate that "SSH isn't the "end all" security solution where, just because you're running it, you won't be attacked, and or compromised" - I'm sort of comparing against it as a benchmark because most of the market I'm looking to serve already allow that access so it would be an acceptable level of risk. – kalenjordan May 16 '14 at 15:04
  • I know that a VPN would be more secure - I'm not looking for the most secure option here. I'm building a product for a platform where I'm in control of the client application as well as the server code. Comparing against SSH is a way for me to know that my solution is as secure as what 99% of these potential customers already have setup. – kalenjordan May 16 '14 at 15:05
  • The reason I'm not looking for the most secure option is because as you say I'm looking to "gain random clients" that can install this server module and then allow my client application (a SaaS app) to connect to it with as little as possible web server / infrastructure configuration (ideally none), while at the same time having a solution that is not introducing a greater measure of risk to their infrastructure than what they already have in place (i.e. SSH with IP whitelist) – kalenjordan May 16 '14 at 15:07
  • I understand what you mean (second message). I think you need to focus on the ultimate goal of what is it your trying to accomplish versus benchmarks. Reasoning for that statements is, if you look at NIST, ITIL, etc., all have great ideas, for the networks they are BASED on. In my implementations, they'd never work. So grab the ideas/concepts, and apply them to your goals, then assess risk from there. E.g., you want to minimize the risk of someone OBTAINING data via this connection (to be continued... char shortage) – munkeyoto May 16 '14 at 15:08
  • by OBTAINING I mean: "seeing, tampering, etc" data between your client and your server. Ask yourself: who needs to connect to whom in this client server? Point A and Point B, then let me ONLY allow them to via the most secure method possible. Rinse and repeat. You can do this on a modular level. Create a spreadsheet w/7 layer OSI and paint the connections along with the protections on each layer. Does that make a bit more sense? – munkeyoto May 16 '14 at 15:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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