The webapi/WUI should have https enabled by default #997

New Issue

tahoe-lafs · 2010-03-13T20:16:37Z

jsgf commented

2010-03-13 20:16:37 +00:00

In the spirit of making the defaults secure, the web interface should have https enabled by default. Plain http is only secure if you assume users will always interact with the server over a secure network, but practice shows that people often connect to remote servers.

This implies that Tahoe should ship with some certificates. These can be any dummy self-signed certs, since we just need secure key negotiation.

In the spirit of making the defaults secure, the web interface should have https enabled by default. Plain http is only secure if you assume users will always interact with the server over a secure network, but practice shows that people often connect to remote servers. This implies that Tahoe should ship with some certificates. These can be any dummy self-signed certs, since we just need secure key negotiation.

tahoe-lafs added the

labels 2010-03-13 20:16:37 +00:00

tahoe-lafs added this to the undecided milestone 2010-03-13 20:16:37 +00:00

imhavoc commented

2010-03-13 20:37:09 +00:00

https will secure the contents of the file, but not the CAPS. The CAPs will still be available to every router/hub/switch along the way. Transmitting the CAP in the URL makes keeping secrets difficult.

chris commented

2010-03-13 20:53:37 +00:00

@jsgf: There is no secure key negotiation with anonymous peers. That is, self-signed certificates will not (by themselves) suffice to protect HTTPS communications across an insecure network (== any non-isolated network). SSH-style trust-on-first-use + continuity of identity might suffice, however. Unfortunately, no browser makes that easy/possible right now. This is a browser bug, but we have to live with it for now.

An alternative that sort-of-works with current browsers is to generate a new CA certificate as part of installing the WUI, and then instruct users to add that CA to their browsers' CA certificate stores.

However, browsers still provide no easy way for users to distinguish between an HTTPS server authenticated by their WUI's CA and by any random (potentially malicious/incompetent/compromised, yet trusted) CA.

@imhavoc: No, URLs are not exposed to routers/hubs/switches when using HTTPS. The entire HTTP conversation is encapsulated inside TLS; midpoints see only TLS setup and encrypted data messages.

@jsgf: There is no secure key negotiation with anonymous peers. That is, self-signed certificates will not (by themselves) suffice to protect HTTPS communications across an insecure network (== any non-isolated network). SSH-style trust-on-first-use + continuity of identity might suffice, however. Unfortunately, no browser makes that easy/possible right now. This is a browser bug, but we have to live with it for now. An alternative that sort-of-works with current browsers is to generate a new CA certificate as part of installing the WUI, and then instruct users to add that CA to their browsers' CA certificate stores. However, browsers still provide no *easy* way for users to distinguish between an HTTPS server authenticated by their WUI's CA and by any random (potentially malicious/incompetent/compromised, yet trusted) CA. @imhavoc: No, URLs are not exposed to routers/hubs/switches when using HTTPS. The entire HTTP conversation is encapsulated inside TLS; midpoints see only TLS setup and encrypted data messages.

jsgf commented

2010-03-13 23:26:53 +00:00

Replying to chris:

@jsgf: There is no secure key negotiation with anonymous peers. That is, self-signed certificates will not (by themselves) suffice to protect HTTPS communications across an insecure network (== any non-isolated network). SSH-style trust-on-first-use + continuity of identity might suffice, however. Unfortunately, no browser makes that easy/possible right now. This is a browser bug, but we have to live with it for now.

Quite right, it doesn't help with MITM. But it is an improvement over plaintext.

An alternative that sort-of-works with current browsers is to generate a new CA certificate as part of installing the WUI, and then instruct users to add that CA to their browsers' CA certificate stores.

Yes. But installing CA certs is pretty tricky to do from browser to browser. But it should be managed somehow, because a self-signed cert will cause browsers to whine.

Replying to [chris](/tahoe-lafs/trac-2024-07-25/issues/997#issuecomment-76285): > @jsgf: There is no secure key negotiation with anonymous peers. That is, self-signed certificates will not (by themselves) suffice to protect HTTPS communications across an insecure network (== any non-isolated network). SSH-style trust-on-first-use + continuity of identity might suffice, however. Unfortunately, no browser makes that easy/possible right now. This is a browser bug, but we have to live with it for now. Quite right, it doesn't help with MITM. But it is an improvement over plaintext. > An alternative that sort-of-works with current browsers is to generate a new CA certificate as part of installing the WUI, and then instruct users to add that CA to their browsers' CA certificate stores. Yes. But installing CA certs is pretty tricky to do from browser to browser. But it should be managed somehow, because a self-signed cert will cause browsers to whine.

davidsarah commented

2010-03-14 02:23:55 +00:00

Replying to imhavoc:

https will secure the contents of the file, but not the CAPS. The CAPs will still be available to every router/hub/switch along the way.

That's not correct; request URLs are encrypted by https.

Transmitting the CAP in the URL makes keeping secrets difficult.

It does, but for other reasons ([[tickets tagged 'capleak']query:status!=closed&keywords~=capleak).

Replying to [imhavoc](/tahoe-lafs/trac-2024-07-25/issues/997#issuecomment-76284): > https will secure the contents of the file, but not the CAPS. The CAPs will still be available to every router/hub/switch along the way. That's not correct; request URLs are encrypted by https. > Transmitting the CAP in the URL makes keeping secrets difficult. It does, but for other reasons ([[tickets tagged 'capleak']query:status!=closed&keywords~=capleak).

warner commented

2010-03-15 19:19:16 +00:00

I really want to encourage users to run their own gateway. I'm a little bit nervous that turning on SSL by default will look like we're suggesting people talk to somebody else's gateway, and would imply that eavesdroppers on the wire between your browser and that gateway are more of a concern than whether your gateway is acting in your own best interests. I recognize that using SSL (even on localhost) is strictly equal-or-more-secure than non-SSL, but I do wonder if it sends the wrong message to users.

Asking users to install a new CA root feels wrong to me.. it teaches them to "improve" their security by adding vulnerabilities into their browser.

The real question is what secrets (i.e. the filecaps) you're revealing to which parties, and whether those are the parties you meant to reveal them to. "http://127.0.0.1/" in the browser is harder to spoof than the collection of (browser shows usual spoofable lock icon)+(address bar shows meaningful DNS name)+(user remembers mapping from DNS name to which gateway they meant to use)+(CA/PKI system is uncompromised and maps DNS name / cert name to the expected cert)+(gateway isn't logging/revealing your filecaps).

Maybe we should discuss the properties of a web gateway which only accepted connections from localhost?

I really want to encourage users to run their own gateway. I'm a little bit nervous that turning on SSL by default will look like we're suggesting people talk to somebody else's gateway, and would imply that eavesdroppers on the wire between your browser and that gateway are more of a concern than whether your gateway is acting in your own best interests. I recognize that using SSL (even on localhost) is strictly equal-or-more-secure than non-SSL, but I do wonder if it sends the wrong message to users. Asking users to install a new CA root feels wrong to me.. it teaches them to "improve" their security by adding vulnerabilities into their browser. The real question is what secrets (i.e. the filecaps) you're revealing to which parties, and whether those are the parties you meant to reveal them to. "<http://127.0.0.1/>" in the browser is harder to spoof than the collection of (browser shows usual spoofable lock icon)+(address bar shows meaningful DNS name)+(user remembers mapping from DNS name to which gateway they meant to use)+(CA/PKI system is uncompromised and maps DNS name / cert name to the expected cert)+(gateway isn't logging/revealing your filecaps). Maybe we should discuss the properties of a web gateway which *only* accepted connections from localhost?

warner added

code-frontend-web

and removed

unknown

labels 2014-09-11 22:20:19 +00:00

Sign in to join this conversation.