StartSSL / StartEncrypt, UX, RLWE, QKD, Post Quantum Crypto, Ring Buffers, Tor Honey Onions

Post date: Jul 10, 2016 9:31:34 AM

StartSSL.com / StartEncrypt Automatic SSL Certificate verification process was kind of broken (?). But funny or not, it's just about the definition. What's secure and what isn't. Why some sites do allow users to upload binary files and why some sites do allow users to redirect. Those are also 'vunerabilities' on the domain / site being authenticated. So in this case, it's so simple to say that it's broken. What's broken? It's not broken. The sites being verified are in one sense broken. It doesn't matter those are major actors. They'll let 'others to use their domain' which is also inherent security risk. As in my previous examples, I've said this is totally normal and this is going to happen over and over again. Is there some kind of official specification what's being considered 'secure' and what isn't? It's just the classic falling between cracks. Single thing isn't a problem, but when you combine those, it'll becomes a huge problem. Then there was the fact that the StartEncrypt client didn't verify the StarEncrypt server certificate. That happens, nothing new. There are plenty of programs which do not do that. And as I've said earlier even some banks recommend no to check certificates, because renewing those is pain in the.... Then it didn't check the MIME type. It was claimed that this allows getting certificates for any site which allows to upload avatars / pictures. That's yet another disputable claim. Of course those sites won't allow uploading such binary files, if those aren't being recognized as images. Or maybe some do, which means that those sites are also broken, and things are again falling between multiple cracks. Which sites allows 'binary file uploads' as images, which aren't images? Probably many. It's just simply too hard to check what the binary file actually contains, right? Incorrect file access rights (666) for the SSL private key is yet another example. Yes, file is readable or can be modified by anyone. But why would anyone give access to the server for non-trusted users? I know, it's yet another issue in this long line of issues. This wasn't anything new, it's always the same problem making hard things easy or easy things hard. There will be always problems at some level. It's also funny to notice that if security tools are this badly broken, what you would expect from most of so called 'normal' software? Hah, security is almost equal to none. Yet of course this shouldn't surprise anyone.
Often I wonder what kind of people are designing the UX. Like in case where you first compose message and then send it and it ends up with some kind of error. Why you can't modify the message, there's only resend option which doesn't allow you to edit the message. I've seen this same problem with multiple apps. I just could say bleep about this. All you can do you can delete the message recompose message and possibly copy paste everything from the previous message to the new message and fix the error. But that's just stupid. Is it really so hard to allow editing message once it's placed in outbound queue? - Yes seems to be the answer. Technically that's nearly impossible engineers say.
Quote from F-Secure: "Key endpoint protection strategies: * Hardening * Prevent malicious applications * Isolate applications from resources"
Ring Learning with Errors (RLWE) - New cryptographic algorithms to protect against quantum computer cryptanalysis.
Of course I had to check Quantum key distribution (QKD) too. We're living interesting times. I were actually familiar with this stuff, but it's good to remined you ever now and then about stuff you're not actually using.
Google's Security article Experimenting with Post-Quantum Cryptography.
Nice old article about Ring Buffers and implementations. - Nothing new, been there done that. But it explains well a few possible fail points if you're implementing ring buffer from scratch.
More Tor attacks. Honey Onions