3

I'm building a desktop app. I'd like websites to be able to communicate with the app over HTTPS. The general idea is that a website could run a JSONP call to https://127.0.0.1:8844 and send data to the desktop app.

The problem is that most newer browsers won't let you run a call in the background to a non-authority-recognized HTTPS site, so my self-signed cert is keeping browsers from calling my app.

The solution I thought of is to register local.myapp.com, point it to 127.0.0.1, and have a cert authority sign the cert for it. The kicker is the app is open-source, so I'll have to distribute the certificate/key to all the clients.

What are the security implications of having this information completely out in the open? Is there another way of allowing modern browsers to send data to a desktop app?

andrew
  • 141
  • 6
  • 1
    Why do you want to let the browser communicate with the app with https and not with plain http, if the communication is localhost only? Because you will need to have the private key on the local machine to use https against your app I see no security advantage with https. – Steffen Ullrich Mar 21 '14 at 19:08
  • 1
    I don't really care about the security advantage, it's more the fact that browsers refuse to communicate with *any* http resource while on an https page, so the only real solution I can think of is to use https in the app itself (because the site(s) that communicate with the app will be using https). – andrew Mar 21 '14 at 19:37
  • 2
    "The kicker is the app is open-source, so I'll have to distribute the certificate/key to all the clients." No you don't. You leave it to the users to get their own certificate. You just describe to them how to implement it. We have exactly the same situation (although not open source): the user can connect to our software hosted by us with our certificate, or he can host everything himself but then he'll have to get his own cert and use that. (http://security.stackexchange.com/questions/52654/risks-associated-with-distributing-encrypted-private-key-with-our-software) –  Mar 21 '14 at 20:33
  • "You leave it to the users to get their own certificate. You just describe to them how to implement it." That's an enormous barrier to entry for your average user. Although this app will most likely get a lot of use from tech people, I can't reasonably expect any user to generate a cert to use my application, much less get it signed by a CA so their browser can talk to it. – andrew Mar 21 '14 at 22:28
  • 1
    I think it is a bad idea to get a public certificate and then pointing your public DNS to a private IP, e.g. 127.0.0.1. Also, it will not work everywhere because local DNS servers like dnswall or public DNS like OpenDNS will remove these DNS entries for security reasons. See http://www.securityfocus.com/archive/1/486606 for one reason they will do this. – Steffen Ullrich Mar 21 '14 at 23:06
  • Offer a paid service to install that certificate! – SPRBRN May 01 '14 at 09:37

2 Answers2

1

Security implications aside for a minute, it seems like this is either a bad idea or just plain won't work in many situations.

My solution, which sucks but isn't the end of the world, is to build browser extensions to communicate between the app and the browser. This way the extension can gather information about the current page, whether http or https, and send it via plaintext http to the desktop app via ajax.

andrew
  • 141
  • 6
0

Research using CORS first rather than JSONP, it is much easier to use, more secure and more reliable as you can do error handling with jQuery. Support is spotty for IE8 and IE9 but all the other major browsers work fine. Your web server backend code just needs to send a few HTTP headers and it starts working with regular AJAX requests.

If you want browsers to accept a self-signed certificate before they use your service then they need to manually type the server IP into the address bar of the web browser first. It will throw an unwarranted big scary warning first, so manually verify the certificate hashes against the real certificate's hashes then store the exception (trust the certificate). Alternatively you can export the certificate from the server to a file, then users can load the certificate file manually into the browser's trust store which is located in the browser settings/preferences.

Receiving a self-signed certificate directly from the website operator (e.g. in person) then storing it in your browser's cache is much more secure than relying on a third-party like a "Certificate Authority" to sign it. This practically eliminates active MITM attacks and issues with compromised CAs signing fake certificates. However for this to work you would also need to purge your browser from all the pre-signed snake oil certificate authorities so only the self-signed certificate is trusted. If you leave them in there, then an attacker with access along one of the router hops to your server (think intelligence agency) can intercept your connection, create a fake certificate on the fly, present you with the fake certificate signed by the compromised CA which your browser already trusts, then actively MITM your connection leaving you completely unaware, unless of course you manually check the connection details and realise you did not get Verisign to sign your self-signed certificate.... With the pre-trusted root CAs removed from the browser, and your self-signed one explicitly trusted this is no longer possible and you will get a legitimate scary warning if the certificate changes.

Obligatory viewing: Moxie Marlinspike and the Future of Authenticity.

NDF1
  • 663
  • 5
  • 7