Hacker News Reader

Comment by j_s | Hacker News Reader

  tells you how to use StartSSL, which generates the key in your browser. 
  Whoops, your private key is now known to another server on this internet

Pardon my ignorance, but I thought the in-browser certificate creation process avoids sending the private key.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ke...

http://www.jroller.com/whoami/entry/browser_generated_certif... (2006)

View on HN

Just wanted to mention that you can alternatively upload your own locally generated CSR to StartSSL instead of using the website to generate a key pair for you.

In this case you are trusting the javascript running in the browser that it does not leak the key it generated. It is safer to just not let the browser ever see the private key.

keypair generation is done by the browser using the <keygen /> element, not by custom JS.

Unless malicious JS is served in place of the <keygen> element, which would be largely undetectable to the user.

How would said malicious JS then install the generated phony certificate in your browser's cert store?

I'm talking about the step where StartSSL generates an SSL private key for you in the browser (unless you know to click "Skip"). No need to install anything in a browser store, it just brings you to a page with a generated SSL certificate using that key.

Interesting tag! I hadn't heard of that.

But even so, unless you actually inspect the live DOM and ensure it's really using that element for your session, and inspect enough of the rest of the code to ensure it's not some misdirection, you can't really trust it.

It's an old deprecated netscape tag. In Netscape/Firefox derived code, it's superceded by the 'crypto' javascript object.

The Netscape specific crypto JS is also gone now: https://bugzilla.mozilla.org/show_bug.cgi?id=1030963 replaced by the Web Crypto API.

Thanks, I didn't know that. But even if the spec says javascript on the page should not be able to extract the private key and XHR it somewhere, it's just a bug away.

<keygen>'s really intended for client certificates used to authenticate to websites. I think that (for example) StartSSL use it to generate the private key you use to log into their site, but any private keys you create on their website for things like websites are generated on their server.

You should never send a private key. Private keys are private. That is a poorly written tutorial - written by someone that may not understand PKI.

You generate the CSR and send that.

It does. But what if StartSSL is compromised (or your connection is MITM'ed) and you're served a page that contains malicious javascript instead of the intended keygen tag? The only way to be sure would be to check the HTML...in addition to the rest of the learning curve of implementing SSL.

if startssl is compromised (and if start ssl doesn't use ssl, allowing for mitm), then I don't imagine you'd have much luck regardless

no matter what practices startssl uses, once your connection to them is compromised or once they are compromised, then the attacker can change what practices startssl suggests to its users.

> then the attacker can change what practices startssl suggests to its users.

Or just issue a cert on its own accord...

by that logic, do you read the source of your key generation binary and then compile it yourself?

or at least consult the md5 on your distill page before running it? oh and make sure md5sum is not altered either.

You are correct. It generates a private key and then sends a SPKAC which is essentially a different format of CSR.

With the exception of SMIME certificates, StartSSL generates the key on their server.

Not true at all. StartSSL can generate the private key for a SSL/TLS cert on the server, but you can skip that step and upload your locally-generated CSR.

Yeah, but when you choose to generate it with them that is how it is done.

Reply on news.ycombinator.com