3

I have a network that is only accessible through bastion servers over ssh. In it, I am developing web applications that are exposed to end users via GUI's served up over websockets. All traffic into and out of the network travels through an SSH tunnel from whatever service host, through the bastion, to the end user's machine.

So, traffic from the network's boundary to the end client is already encrypted. And, I already have a system setup for associating end users with SSH-RSA key pairs that are rotated periodically.

So, here's my crazy idea:

On any web app in the network that requires user authentication, have the end user provide their username on the network, as well as their public key. Have the web app's authentication service verify that this public key is indeed already associated with the end user in the network's keystore, then generate a challenge using the key. Client side, the end user decrypts the challenge using their private key and presents the end result to the server for authentication.

Here's the kicker: a load of services in this network are implemented in JavaScript on NodeJS. Because NodeJS can call system services, I can offload the work of generating challenges using public keys to a more traditional process. But, client side, I might need to decrypt the challenge in-browser using the private key.

Getting the private key into the browser is easy enough. Whether or not loading the private key into a browser is even a good idea is another question, entirely.

But, more specifically:

  1. Are there any blazing "Oh, don't do that!" security flaws in the setup summarized above?
  2. What are a few standard packages used in Linux for generating challenges using an RSA public key?
  3. Does anyone know of a good package for decrypting messages using a public RSA key implemented in JavaScript?
StudentsTea
  • 206
  • 1
  • 3
  • 10
  • "...and presents the end result to the server for authentication", how do they do that? What are your security goals? Mutual authentication, client-side authentication only? What is your threat model? Do you want to protect the clients from a malicious server? Server from malicious clients? Etc. – mikeazo Jul 24 '15 at 14:58
  • You should definitely read [What's wrong with in-browser cryptography?](http://tonyarcieri.com/whats-wrong-with-webcrypto) and [Javascript Cryptography Considered Harmful](https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/) – mikeazo Jul 24 '15 at 15:00
  • By transmitting the now clear text challenge phrase to the server via websockets, tunneled through an SSH connection. Security goals: authenticate the user. What's a threat model? No. No. etc. – StudentsTea Jul 24 '15 at 15:01
  • Have read it. My thinking is that the runtime isn't vulnerable because it is delivered to the client over an SSH tunnel. – StudentsTea Jul 24 '15 at 15:03
  • I won't be generating random numbers in the browser. Keys are generated the usual way, using traditional methods for setting up users on ssh servers. – StudentsTea Jul 24 '15 at 15:08
  • What's a threat model? well, you've already started building yours by answering my questions. You are not worried about protecting clients from a malicious server and not worried about protecting the server from malicious clients. – mikeazo Jul 24 '15 at 15:09
  • The only thing that happens in-browser is decryption of a challenge phrase. – StudentsTea Jul 24 '15 at 15:10
  • I'm not worried because those threats have already been mitigated: all server-client communication happens over an ssh tunnel. – StudentsTea Jul 24 '15 at 15:10
  • How does the browser get access to the SSH-RSA key pair? – mikeazo Jul 24 '15 at 15:12
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/26201/discussion-between-mikeazo-and-go-f-yer-pedantry). – mikeazo Jul 24 '15 at 15:14
  • That hasn't been decided yet. One thought was just to have the end user put it in the run time from the local machine, which is akin to putting a public key on an internet facing server, I think. – StudentsTea Jul 24 '15 at 15:15

1 Answers1

1
  1. Are there any blazing "Oh, don't do that!" security flaws in the setup summarized above?

The basic protocol you are proposing is: client identifies themselves, server checks the public key and verifies that they are a valid user, server encrypts a challenge using the public key, client decrypts to get the challenge back and returns it as proof of knowing the private key.

I don't see any blazing issues. It may be better to follow what SSH itself does for public key authentication as shown in RFC 4252, section 7. There, they have the client sign something with the private key that the server can then verify. Always good to stick with standards.

  1. What are a few standard packages used in Linux for generating challenges using an RSA public key?

If you have openssl, I'd do this openssl rand -base64 16 (or possibly 32 bytes).

Otherwise, you can use /dev/random (or possibly /dev/urandom if absolutely necessary). Something like this head -c 16 /dev/random | base64. See this for more details

  1. Does anyone know of a good package for decrypting messages using a public private RSA key implemented in JavaScript?

A number of these libraries support RSA. Not sure how good they are and how easy it will be to transform the SSH private key into something they can use.

This answer is a summary of our chat

Community
  • 1
mikeazo
  • 2,827
  • 12
  • 29
  • 1
    Considering how vulnerable browsers are to XSS attacks, I'm hesitant to use client-signed messages for authentication. Anyone who has the signed message outbound from the client effectively has the ability to impersonate the end user. I suppose this could also be said of the response half of a server-generated challenge-response, though. – StudentsTea Jul 24 '15 at 18:13
  • @GoFYerPedantry if an attacker can inject javascript, and the private key is loaded into the javascript memory, they can also get it. That to me is a bigger concern since then they could establish the SSH connection. But you did say you weren't worried about protecting the server from malicious clients :) – mikeazo Jul 24 '15 at 18:20
  • More to the point, I said I didn't like the idea of exposing the private key to the browser. :) – StudentsTea Jul 24 '15 at 18:23
  • @GoFYerPedantry, true, true. Another possibly cool option would be to have the ssh connection (in addition to establishing the tunnel) return a one-time-use auth token for the user. Not sure how that would be passed to the browser, though. – mikeazo Jul 24 '15 at 18:30
  • I guess a keypoint is--how many permissions does a key buy the person wielding it? The client needs to transmit some identifying _thing_ to the server--whether it be a traditional password, response to a challenge, client-generated signature, and so on. As long as that _thing_ is changed frequently, hard to brute force and follows the principle of least permissions, we've done the best we can. ...right? :/ – StudentsTea Jul 24 '15 at 18:31
  • I was thinking about that, having the sshd generate a one-time key. But, like you said, the attack surface increases so much trying to come up with a novel way to get that key into the connection with the browser. :( – StudentsTea Jul 24 '15 at 18:34
  • BTW, just found [this question](https://security.stackexchange.com/questions/44004/is-it-possible-to-use-a-gpg-or-ssh-key-for-web-based-authentication-in-a-secure) you may be interested in. – mikeazo Jul 24 '15 at 18:34
  • @GoFYerPedantry In fact, [look at this comment](https://security.stackexchange.com/questions/44004/is-it-possible-to-use-a-gpg-or-ssh-key-for-web-based-authentication-in-a-secure#comment138731_44013). You sure you don't have two accounts :) – mikeazo Jul 24 '15 at 18:36
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/26212/discussion-between-go-f-yer-pedantry-and-mikeazo). – StudentsTea Jul 24 '15 at 18:40