141–150 of 188 posts
Earlier quoted context omitted.
I put the CVE id in my "reason" and it went through with no charge.
Gotta try that after i catched some sleep. Got no reply from them on twitter. I'd expect them to an annouce this officialy though.
Article raises a good point. Seeing this repeated 50+ times made me cringe though if ((req = X509_REQ_new()) == NULL) ERROR_OUT(ERR_SSL, done); seriously.. also, writing new code and not using Rust, or D, or even C++. WTFs like the above are par for the course when you're writing in a 40 year old language without any features of modern low-level languages.
Earlier quoted context omitted.
I don't understand. What part of TLS are you calling "simple"?
The interface between an application that wants to communicate using TLS and perform related tasks and a library that implements TLS can and should be simple - at least for the 90% of common use cases. The whole point of the original article is that the interface of OpenSSL is horrible and undocumented. Consider how the article's author was not originally interested in looking at the internals of OpenSSL. All they wa…
However, the functionality openssl provides is much bigger than most of the commenters can imagine. It's not easy at all.
>OpenSSL is equivalent to monkeys throwing feces at the wall. It is, bar none, the worst library I have ever worked with Ah, he haven't worked with MS Crypto APIs. I was implementing TLS/SSL in one of the services working at MS . I couldn't figure out many things from MSDN and samples - they would not cover error and some variations code paths, and there was just no way to figure it out. And recovery would be somethi…
The absolute worst API in the history of computers is the Microsoft Text Services Framework (TSF) API. It's incomprehensible, nearly undocumented, 10x more complicated than necessary, and even Microsoft doesn't understand how it works and hates it.
And with it being C, doing a proper operator spacing+indentation of the whole source should be as easy as running it through a tool (yes, auto indent is always better than a broken indent).
What's the next discovery? The core is all php and there are zero tests?
Earlier quoted context omitted.
I guess you don't agree with Poul-Henning Kamp in his FOSDEM keynote this year: https://www.youtube.com/watch?v=fwcl17Q0bpk (around 15:00) His claim is that browsers treating websites with self-signed certificates as less secure than non-encrypted websites by displaying big fat warnings is just about the greatest gift we can give to organisations like the NSA. It's not true that there is no material distinction betwe…
PHK says many things I disagree with. You can't make browsers simply treat self-signed certificates the same as plain HTTP. You still have to warn the user that their desire for a secure connection (conveyed by their request to retrieve an https URL) cannot be fulfilled, and do so in a way that assures all users will notice before they do something like, say, type in their password. There is very little self-signed H…
Normal users do not enter URLs in their browsers, much less https ones, and do not pay attention to the https prefix when clicking a link or pasting an URL, so the client retrieving an https URL usually does not indicate a desire from the user to have a secure connection.
I believe that users have been trained to pay attention to the presence of padlocks and colors in the address bar, not to the presence of the "https" prefix, so that self-signed HTTPS could look the same as plain HTTP from that perspective and I don't believe security harm would ensue.
> There is very little self-signed HTTPS traffic out there. The NSA assuredly has the resources to MITM all of it.
I find this doubtful. I am willing to believe that the NSA might be passively snooping on a large portion of HTTP traffic, but performing active attacks, even when you have the resources, is a lot harder to be doing smartly (unlike passive attacks, which are invisible).
If the NSA were routinely MITMing self-signed HTTPS traffic, knowledgeable users would have noticed. They would be investigating under which conditions, and along which routes, does the MITM take place. As nobody seems to have witnessed this, I doubt that is happening now, or that it is likely to happen in an indiscriminate way.
> You might be willing to gamble your own security, but you should not gamble everyone's security.
Even then, how is MITMed HTTPS traffic worse than passively monitored, and potentientally MITMable, HTTP traffic?
As for your point about training users to ignore security warnings: blame the browsers, not the websites. If using self-signed HTTPS is no worse than HTTP, those messages are stupid, and I'm not going to give up on the additional security of self-signed HTTPS just because browsers are doing something stupid with it.
I've done quite a bit of programming with the OpenSSL library and this article is only scratching the surface of the awfulness. Documentation is horrible to non-existent, you really do need to go spelunking into the source to figure out how things work, and the code really is that horrible. The worst thing is that error reporting is not consistent - sometimes -1 means error, other times 0 means error, other times 0 m…
So I only have a basic/intermediate understanding of SSL and X509, but I am curious about your opinion: Is the awful code design just a flaw in that particular implementation, or are the standards involved so hard to implement correctly?
Earlier quoted context omitted.
O.K. This is probably a stupid question but if it was apparent to many that the code of OpenSSL was horrible why people kept using it and nobody tried to re-factor it? How it is possible that such a popular and critical piece of opensource software survived the years without a complete face-lift and nobody wrote thorogh documentation?
It is really difficult to refactor such things at the public API layer once they are widely adopted by 3rd party projects. Take the aforementioned error return inconsistencies -- how do you possibly deal with refactoring that for consistency when so many other projects are consuming OpenSSL as a library? You're trading one big problem (new clients are likely to get error return handling wrong) with another (if you mo…
But how did it ever get so widely adopted, if it's so hard to use?
And even if it is widely adopted, that still shouldn't stop anyone from forking it and fixing all the problems.
I've done quite a bit of programming with the OpenSSL library and this article is only scratching the surface of the awfulness. Documentation is horrible to non-existent, you really do need to go spelunking into the source to figure out how things work, and the code really is that horrible. The worst thing is that error reporting is not consistent - sometimes -1 means error, other times 0 means error, other times 0 m…
O.K. This is probably a stupid question but if it was apparent to many that the code of OpenSSL was horrible why people kept using it and nobody tried to re-factor it? How it is possible that such a popular and critical piece of opensource software survived the years without a complete face-lift and nobody wrote thorogh documentation?
Its a pattern that you can watch on many IT-Projects.
Some "Key-People" like a project (for whatever reason) and a mass of developer follow them.
And than a thing get "standard" and more and more people use it.