Show HN: Sslhash: SSL without a certificate authority • Hacker News Board

Re: Show HN: Sslhash: SSL without a certificate authority

#11

Post by jD91mZM2 » Fri, Feb 09, 2018, 2:38 PM UTC

barrystaes wrote: post #9

Rather pointless to compare the SSL certificate to a hash ofcourse. Why not just compare it to a copy of the certificate. No need to obfuscate and allow user to be fooled with changed hash.

The hash is a lot smaller and less likely to be subject of a copy-paste error ¯\_(ツ)_/¯

Re: Show HN: Sslhash: SSL without a certificate authority

#12

Post by jD91mZM2 » Fri, Feb 09, 2018, 2:40 PM UTC

lasdfas wrote: post #10

nemothekid wrote: post #3

Earlier quoted context omitted.

You would probably need some sort of "authority" to redistribute the hashes.

One of the main reasons for the library is no need for cert authority. Why not just create a regular cert Authority certificate and put the trusted authority cert on the clients. That makes it so you almost never have to change the clients certs. Also, it's supported by standard TLS libraries and clients.

True, didn't think of that. The server would still have to generate it using a command though... I like having things automated.

Re: Show HN: Sslhash: SSL without a certificate authority

#13

Post by jD91mZM2 » Fri, Feb 09, 2018, 7:43 PM UTC

lasdfas wrote: post #2

How does expiration work? What happens if an TLS/SSL cert is leaked/compromised? Change the clients as well?

Since only the keypair is cached, certificates are generated on each startup. This means they never expire (unless you run your application without any interruptions for a whole year).

But yeah, if they're leaked you just gotta re-send them to the clients. This isn't meant for large professional projects, only for stuff where the convenience outweights the pros of using a proper certificate.