How to enhance WebUI default security against capability eavesdropping?

[amontero]

I'm setting up a LAN grid that where I would like to protect storage nodes WebUIs from casual eavesdroppers. I connect to storage nodes via WebUI to do checks and tests, and would like to be a bit safer from wireless sniffers at public hotspots, for instance.

I assume that enabling SSL for all node's WebUIs would be enough for that, maybe I've overlooked something. Just common-sense rule-of-thumb: (most of)SSL will be better than NO SSL.

Then I thought that the easiest way to do this is, not to even generate any certs locally, but reuse the "private/node.pem" existing one. Looks the easiest, good karma points. Perhaps that's not possible/advisable and is a blatant "no-no" that I could not be aware of. Tried reading the code a little and read ​https://github.com/tahoe-lafs/pycryptopp/blob/master/README.ed25519.rst and I'm not sure. But, here I've could be completely mislead and I don't understand most of it. My doubts are:

• what security will have this "node.pem" key for webui SSL?
• is "node.pem" even suitable for using it as SSL cert?

I asked in IRC and was given nice alternatives, such as vpn, lafs-rpg or ssh tunnels, but doing by enabling just SSL I seem to understand that's not as easy and secure as it sounds. But here I might fall short on understandings of some crypto/PKI concepts. So, anyway at least as a FAQ I would like to know if it is possible or if it can be achieved someway. Here it might raise ideas, such as "why we don't generate a default 'private/webui.pem' and recommend in tahoe.cfg comments?". I think that switching to from NO SSL to SSL WebUI is worth having, isn't it?

I think making this a bit clear for non cryptologists could at least be a nice security FAQ, even if not advisable.

[daira]

private/node.pem is only used for foolscap connections (see docs/configuration.rst#other-files-in-basedir​). The setting to use for [node]web.port to run the web-API over SSL is mentioned in docs/frontends/webapi.rst#enabling-the-web-api-port​, but not very prominently:

Using "ssl:3456:privateKey=mykey.pem:certKey=cert.pem" runs an SSL server.

[zooko]

So, do the docs referenced in comment:4 answer your questions, amontero? If so, then I guess the next-step is to arrange things so that the next user finds the necessary docs.

[amontero]

Replying to zooko:

So, do the docs referenced in comment:4 answer your questions, amontero? If so, then I guess the next-step is to arrange things so that the next user finds the necessary docs.

I was aware of the SSL enabling syntax for [node].web.port setting, it's nicely documented as it is now. What I would like to know is if the already present "node.pem" file can be used as a webport SSL certificate (I didn't succeeded at it).

I think that having a cert handy in the node dir would make easier for people to enable SSL for the webui by avoiding cert generation. Perhaps self-signed certs aren't the most secure option, but better than no SSL, anyways.

[daira]

Replying to amontero:

Replying to zooko:

So, do the docs referenced in comment:4 answer your questions, amontero? If so, then I guess the next-step is to arrange things so that the next user finds the necessary docs.

I was aware of the SSL enabling syntax for [node].web.port setting, it's nicely documented as it is now. What I would like to know is if the already present "node.pem" file can be used as a webport SSL certificate (I didn't succeeded at it).

I don't know whether that can be made to work but it's probably not a good idea, anyway. Use a separate private key generated by openssl:

openssl genrsa -out mykey.pem 4096
openssl rsa -pubout -in mykey.pem -out publickey.pem

(and then get a certificate on publickey.pem), or, for a self-signed cert with 100-year validity:

openssl req -x509 -newkey rsa:4096 -keyout mykey.pem -out cert.pem -days 36524

[amontero]

Replying to daira:

I don't know whether that can be made to work but it's probably not a good idea, anyway. Use a separate private key generated by openssl:

openssl genrsa -out mykey.pem 4096
openssl rsa -pubout -in mykey.pem -out publickey.pem

(and then get a certificate on publickey.pem), or, for a self-signed cert with 100-year validity:

openssl req -x509 -newkey rsa:4096 -keyout mykey.pem -out cert.pem -days 36524

Having to deal with openssl command and options can be troublesome for some users. I want to avoid them that, if possible. Using the "node.pem" cert would be a great way to achieve it.

[zooko]

Replying to amontero:

Having to deal with openssl command and options can be troublesome for some users. I want to avoid them that, if possible. Using the "node.pem" cert would be a great way to achieve it.

Suppose that you could use the "node.pem" cert, or suppose that the Tahoe-LAFS gateway would generate a self-signed key automatically (the equivalent of the command-lines described in comment:8. Then the users could connect to it, but they would get a certificate warning that they would have to click through, which is kind of hard to click through on modern Firefoxes. Also, if they do click through that warning, then an attacker could hijack their connection and read the contents of the session and forge contents.

So, maybe that's not worth doing?

[amontero]

But at least, if the user browses the WebUI after it being installed to check if it works, he/she will add a browser exception. Later, if someone tries to do any nasty MITM attack, a browser warning will him/her a warning of that an attack/eavesdrop might be in progress. No SSL would not alert you in any form. I'm aware that this is far from be completely secure, but at least, it could provide some degree of confidentiality.

[daira]

I'm not entirely sure about this, but as far as I understand: A browser certificate exception does not mean "pin the certificate I just saw to the domain name for this site and warn me again if the cert changes". It means "suppress all future warnings for this domain name, thus making SSL useless for this domain".

[amontero]

Ops. I'm assuming here that the exception is tied to a particular certificate serial/id. However, I could not back this when posting. I've researched a little and found this about certificate exceptions and serials: ​https://support.mozilla.org/ca/kb/secure-connection-failed-error-message#w_the-certificate-contains-the-same-serial-number-as-another-certificate

However, I'm not sure if the cert serial is tied to some private key info in a way that it can't be forged easily with any MITM attacks.

As far as I can tell, this error would be a warning sign enough that someone is doing nasty things with the connection. At least, an improvement over current situation good enough for me. This does not prevents you doing some more advanced cert management, if you care about it. That should be clearly stated in docs and as comments in cfg file.

[daira]

Replying to amontero:

Ops. I'm assuming here that the exception is tied to a particular certificate serial/id. However, I could not back this when posting. I've researched a little and found this about certificate exceptions and serials: ​https://support.mozilla.org/ca/kb/secure-connection-failed-error-message#w_the-certificate-contains-the-same-serial-number-as-another-certificate

That page does not describe what the semantics of a certificate exception are. The point you linked to is referring to the error case where two distinct certs have the same serial number, which is not something that an attacker would do.

[amontero]

I'm not any deep in how MITM attacks work, just general knowledge. I assume that any-SSL could work like this:

1. You install a Tahoe-LAFS node as usual.
2. Since you have a cert available, as instructed by the docs, you just enable the any-SSL autosigned cert, maybe by just uncommenting a web.port setting to use them.
3. You browse to check that the node works OK, adding the exception as it's a first.
4. You keep using SSL (in that browser) thanks to the exception. Hey, we can even publish the cert fingerprint to WebUI to check at any moment! (like the first time you browse from a different computer)
5. Someday, some nasty sniffing starts happening in the LAN. You're safe.
6. Worse, someone attempts MITM. Now you could at least get a warning sign that you're under fire. You better check fingerprints.

I'm aware that 6 validity depends on certificate inners and browser behavior that sometimes I'm just assuming, but not certain about it. It depends on how well browsers (ie client-side) shield you from each one of all the range of attacks. But at least would rise a little the bar in some scenarios, as point 5 would stand. However, here I'm at the limit of crypto/MITM knowledge and any assumption could be wrong. It might only prevent against sniffing and not be safe even to simplest MITM, not sure.

[daira]

As far as I understand, once you've added an exception you no longer get any warnings at all about active attacks. Yes, I agree that's not how it should work.

[amontero]

Replying to daira:

As far as I understand, once you've added an exception you no longer get any warnings at all about active attacks. Yes, I agree that's not how it should work.

But AFAIK, you'll get a warning against any MITM that can not fake the same exact cert you added as trusted from your browser. I tried simply regenerating a new cert for a node and the cert warning pops up again. That's nice to have. Also, I suspect that browsers match trusted certs by looking at their fingerprints (difficult to fake, AFAIK).

And still, it would prevent passive snooping/sniffing of cleartext traffic. Nice, too. Of course, it should be clearly documented which attacks SSL would prevent and which not.

[daira]

Replying to amontero:

I tried simply regenerating a new cert for a node and the cert warning pops up again. That's nice to have.

Okay, that's not how I thought it worked. Good to know.

[amontero]

So, after you have connected to a node's WebUI and accepted its cert, you'll get a cert warning if someone later attempts MITMing and you'll be safe against sniffers, also. Isn't that worthwhile to have? If the above is right, I propose a feature request consisting in:

• Auto generating a SSL cert in "private/webui.{key,crt,csr}"
• Add a commented line to the generated tahoe.cfg with the WebUI configured, with appropiate reference to docs.

[daira]

I don't think we can generate a .csr that would be useful, since we don't know the server's intended domain (Common Name) or Organisation. That wouldn't prevent us generating the .key and self-signed .crt; I'm undecided on that part.