Unfortunately, it's not so great at that. I have an HTC Desire (Bravo in the USA) that still works and I'd like to reuse as a SIP client. Unfortunately, it only runs CM 7.2. That would be fine if it were a patched version, but the latest nightly build was 2013 and that's so old that it doesn't contain an up-to-date certificate list or an SSL client library that supports modern versions of the TLS protocol, meaning that you can't use it for anything network connected.
Sure, the device is pretty old, but it has a 1GHz CPU, 512MB of RAM, and up to 32GB of flash on the SD card: that's ample for a lot of uses (it wasn't so long ago that I was using a desktop less powerful!) and throwing it away seems horribly wasteful. It was launched in 2010 and the last release (not nightly) from CM was 2012. That's less long-term support than Apple gives for iOS devices and Google gives for Nexus devices. Unfortunately, there's not much money to be made in supporting hardware that the manufacturers consider to be obsolete.
It's really hard to come up with a scenario in which the problem that leap seconds solve actually exists.
English: I don't mean to belittle you.
American: I mean to belittle you.
English: With all due respect.
American: With no respect.
English: You're almost right.
American: You are completely wrong in every possible way.
English: I'm sorry but...
American: I'm not sorry, this is your fault.
I hope this helps.
The absolute irony is that visiting a site with a self-signed certificate shows the user a warning error (I understand why, don't worry) yet the resulting HTTPS exchange is actually immune to any and all eavesdropping. When visiting a site with a cert authority signed certificate, no error is displayed, yet this connection is vulnerable to anyone who has broken/intercepted the chain of trust
Not quite. Both connections are entirely safe from passive eavesdropping. Even if I've compromised a root cert that you're using, that doesn't let me decrypt TLS traffic. It does mean that if I am actively performing a man in the middle attack on you, then you won't notice, because during the initial key exchange you'll connect to me and establish a secure connection and I'll connect to the remote server and establish a secure connection. You'll trust me because I'll use a cert signed by one that I trust. The difference between this and a self-signed cert is that when the server uses a self-signed cert, there's no need for me to compromise a root cert that you trust: I can still perform the MITM attack and you won't know the difference.
Certificate pinning protects you from this to a degree: If you connect to a server twice and the certificate changes, then there may be a problem. On the other hand, there might not be, and with a self-signed cert, you can't revoke it if it's compromised and you can't easily advertise the fact that this is a replacement cert from the same person (unless you properly self-sign, rather than simply not signing, and people pin your signing cert).
Certificate transparency protects in both cases, by providing a public log of all of the certificates that have been seen by people connecting to the server. If the server operator sees a cert that they didn't issue, or if you see a cert that's not the same one that other people are seeing, then something is wrong.
APL is a write-only language. I can write programs in APL, but I can't read any of them. -- Roy Keir