51–60 of 89 posts
https://github.com/openssl/openssl/commit/bc8923b1ec9c467755...
I noticed (in that commit anyway) there were no tests changed. Is it pretty standard not to test things like this? If I find a major bug in code I write, I usually write a test first and TTD until it's fixed.
Earlier quoted context omitted.
I think people underestimate how many products use OpenSSL... http://www.pcworld.com/article/2143440/server-makers-rushing... http://www.networkworld.com/article/2176022/router/heartblee... It sounds kind of stupid, but i'm thinking the best short-term way to secure an exposed OpenVPN tunnel against future OpenSSL TLS holes may be two layers of encrypted traffic. One static key tunnel to prevent public TLS holes from…
You don't need another layer of encryption, just another layer of authentication protects you from attacks that require an active mitm adversary (as basically all attacks on TLS do). OpenVPN has offered such an option for a long time: https://community.openvpn.net/openvpn/wiki/Hardening#Useof--... This wraps just the TLS control channel, which has low traffic and thus results in a small overhead. The data channel is…
Since most(1) web browsers do not use OpenSSL, CVE-2014-0224 is not going to be a big concern for people browsing using SSL, but it is a concern for machine-to-machine communication where using OpenSSL on both ends will be common. Given that this also affects 0.9.8 there are going to be lots of backend systems that need upgrading. (1) Apparently Chrome on Android is the odd man out in using OpenSSL, but I don't know…
If I'm understanding the CVE correctly, it has nothing to do with the browser. It's when it's on the Server, an attacker could just make OpenSSL think their "browser" doesn't support all of the good algo's and eventually cycle through it's available algo's until a relatively insecure one is decided upon (like the relatively weak CBC algo's). So, it is a potential threat to servers since most web server are *nix based…
Specifically,
With any OpenSSL client talking to an OpenSSL 1.0.1
server, an attacker can inject CCS messages to fixate the
bad keys at both ends but the Finished hashes will still
line up. So it's possible for the attacker to decrypt
and/or hijack the connection completely.Earlier quoted context omitted.
Happy to see you guys working on this. Is there a way to specify that donations should go to the LibreSSL effort rather than to the OpenBSD foundation as a whole?
That is a weird request to me. Telling that it should go to the LibreSSL effort is very much like telling OpenBSD developers what they should work on. The way I understood it, most OpenBSD developers are not for hire, not in a manner like this anyhow. These people work on the things they want to work on, and they share the result of their work as a gift to the world. Donations are a gift in return, and the funding en…
Earlier quoted context omitted.
That is a weird request to me. Telling that it should go to the LibreSSL effort is very much like telling OpenBSD developers what they should work on. The way I understood it, most OpenBSD developers are not for hire, not in a manner like this anyhow. These people work on the things they want to work on, and they share the result of their work as a gift to the world. Donations are a gift in return, and the funding en…
It's simple: I have no current use for OpenBSD but I would use LibreSSL and I know a ton of other people in exactly the same boat. So I'd like my contributions to go where they make the most effect for me.
If you want to deny the project its money and only contribute to a part of it, the only way I can see that happening right now is that you hire a developer to work on the part you want.
Also, don't forget that developing software on OpenBSD is likely to make that software better (there are features that make OpenBSD a good development platform; and the fact that code is tested on many different hardware platforms helps). So while you might not be using OpenBSD, chances are the system is affecting you positively nevertheless. I'd also encourage you to look at how many other projects use code from OpenBSD. Do you use Android per chance?
Earlier quoted context omitted.
That is a weird request to me. Telling that it should go to the LibreSSL effort is very much like telling OpenBSD developers what they should work on. The way I understood it, most OpenBSD developers are not for hire, not in a manner like this anyhow. These people work on the things they want to work on, and they share the result of their work as a gift to the world. Donations are a gift in return, and the funding en…
It's simple: I have no current use for OpenBSD but I would use LibreSSL and I know a ton of other people in exactly the same boat. So I'd like my contributions to go where they make the most effect for me.
Earlier quoted context omitted.
Two of them, CVE-2014-0198 and CVE-2010-5298. We haven't even started looking at the protocol code. I'll also note that "This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common." is pretty misleading. nginx is affected, is not multithreaded, but is fairly common.
Happy to see you guys working on this. Is there a way to specify that donations should go to the LibreSSL effort rather than to the OpenBSD foundation as a whole?
I think you get a pretty decent return on investment even if your dollars support openbsd features you don't use. All of us working on libressl are working in it because we work on openbsd, and we work on openbsd because others have made it a viable platform for us. Basically you may not care about openbsd desktops, but I do, and I'm only working on libressl because of that. Paying me market rates for this work would get a lot less done.
Particular example: libressl exists in part because of previous work done on exploit mitigation. Without that, there'd be no libressl.
Or, to put it another way, if you were to donate to me, I'd probably turn around and forward that money to openbsd foundation anyway.
All that said, you can mention that your donation is for libressl. That doesn't guarantee anything, but I'm sure there are unofficial tallies.
The large volume of vulnerabilities coming out of OpenSSL are worrying, but it likely reflects the increased effort being put into auditing and fuzzing the code after Heartbleed. What is more worrying is the many other critical pieces of software that have nowhere near the level of scrutiny that OpenSSL is receiving currently.
Searching for vulnerabilities is just like mining for gold: you go for the richest veins first and OpenSSL is deployed widely enough and in enough places where it really matters that it is currently a priority item. I guess until a couple of weeks ago OpenSSL was 'one of many other critical pieces of software that have nowhere near the level of scrutiny that WordPress (and I know you don't meant Wordpress) is receivi…
Having been around in the '90s, with the instant root shell exploits and whatnot, I tend to think of Heartbleed as more of a 6.
Debian advisory: https://lists.debian.org/debian-security-announce/2014/msg00... Red Hat 6 advisory: https://rhn.redhat.com/errata/RHSA-2014-0625.html Red Hat 5 advisory: https://rhn.redhat.com/errata/RHSA-2014-0624.html Ubuntu advisory: https://lists.ubuntu.com/archives/ubuntu-security-announce/2...
Anybody know what the difference is between Ubuntu package openssl 1.0.1e-3ubuntu1.2 and openssl 1.0.1e-3ubuntu1.4