2

I want to build something, but I haven't seen it before. Maybe you have?

I'd like to build a HTML5 app, served to modern browsers and phones from a microcomputer (e.g. BBB). The microcomputer would be an open Access Point (not necessarily connected to the internet)

Clients could connect to the AP and see the app. Think of a clickwrap EULA on a wifi AP, but it did useful and nice things for you. An app.

The App needs secure communication. If I use HTTPS, then I'd need an SSL cert. For what domain name? And one for each microcomputer? I couldn't share them or they'd be "compromised" and revoked? That doesn't seem to work or scale. Users are trained to not accept self-signed certs. It's horrible UX to work against and undo that training.

Really, I just need what SSH has:

  1. Setup a new server with SSH, it makes it's own keys.
  2. ssh to a new server and get a new fingerprint: "This is new, accept?"
  3. ssh to a known server with a different fingerprint: "Something is wrong!"

This question talked about DANE/RFC 6698. But that requires DNS (and a connection to the internet), and doesn't seem to be supported by browsers.

I just want it to be as good as ssh. I don't need centralized identity. Future versions would manage identity by sharing fingerprints between clients.

In step step 2 "new fingerprints", modern browsers show a scary warning. For early adopters that's fine as a start. But for regular users, I'd prefer not to scare/untrain them. What I really want is a keyring like known_hosts.

Is anyone thinking about that for HTTPS and browsers?

Thanks!

Community
  • 1
Michael Cole
  • 288
  • 1
  • 8
  • 1
    Note: The behaviour that you talk about in points 2 and 3 is known as [Trust on First Use (TOFU)](https://en.wikipedia.org/wiki/Trust_on_first_use). – StackzOfZtuff Jun 28 '15 at 15:42
  • "[Perspectives](http://perspectives-project.org/) is a browser extension that helps to verify whether your connection to any web site really is secure. It does this by checking the connection certificate with multiple observers hosted around the world." – Michael Cole Jun 28 '15 at 15:52
  • Unfortunately [no support for Chrome - "wont fix"](https://groups.google.com/forum/#!topic/perspectives-dev/mLBHlDA0BlI) – Michael Cole Jun 28 '15 at 15:59
  • 1
    DNS is not the internet. – Aron Jun 29 '15 at 19:13
  • Also take a look at https://letsencrypt.org – Aron Jun 29 '15 at 19:19

1 Answers1

2

What you describe is https with self-signed certificates, i.e.

  1. Setup a new server with SSH, it makes it's own keys.

Setup a https server with a self-signed certificate.

  1. ssh to a new server and get a new fingerprint: "This is new, accept?"

Connect to the new server with the browser. You get a warning but can tell he browser to add an exception.

  1. ssh to a known server with a different fingerprint: "Something is wrong!"

Connect again with the browser. It will tell you that something is wrong because the exception does not match any more. If you've used HSTS then you would not even have an option to override.

In both case the second step is the critical one, i.e. you should only accept the certificate from the server if you've verified the fingerprint and you've got the correct fingerprint in a secure way (maybe while setting up the server).

Michael Cole
  • 288
  • 1
  • 8
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • [HSTS](https://www.owasp.org/index.php/HTTP_Strict_Transport_Security) looks great - thanks! In step step 2 "new fingerprints", modern browsers show a scary warning. For early adopters that's fine as a start. But for regular users, I'd prefer not to untrain them. What I really want is a keyring like `known_hosts`. Is anyone thinking about that for HTTPS and browsers? – Michael Cole Jun 28 '15 at 15:32
  • 2
    @MichaelCole: browsers show a scary warning because you should not just click through but actually know what you do and verify the certificate. This is the same with the prompt you get with SSH where you also are supposed to verify the key and not simply accept it. And once you've accepted the certificate it is stored as trusted for this host, similar to known_hosts. – Steffen Ullrich Jun 28 '15 at 16:43