Has anyone seen an explanation for why this effort isn't being undertaken together with the OpenSSL team?
I would appreciate so much to see a link to corresponding discussions/blog posts in the security communities.
LibreSSL
171–180 of 262 posts
Re: LibreSSL
#172I may have a stupid question but... While I really enjoy Theo's talks and writings, I wonder if the fact that the VCS is CVS ain't a security issue in itself? It's been really a long time I haven't used CVS but I remember that attempt to introduce backdoors in projects using Git as a (D)VCS have been caught (it was in the Linux kernel I think). IIRC some attempts were caught precisely because it's hard to fake SHA ha…
Git uses SHA-1 hashes, which have not been considered cryptographically secure since 2005. Git and CVS are both just tools. They each provide a server implementation, but it's uncommon to use either of these for write access in large projects. It's more common to wrap CVS or Git with a different frontend like HTTPS or SSH. My guess is that the OpenBSD guys use OpenSSH. This team is fanatical about security and proces…
Linus Torvalds: "the point is the SHA-1, as far as Git is concerned, isn't even a security feature. It's purely a consistency check. The security parts are elsewhere, so a lot of people assume that since Git uses SHA-1 and SHA-1 is used for cryptographically secure stuff, they think that, OK, it's a huge security feature. It has nothing at all to do with security, it's just the best hash you can get."
Re: LibreSSL
#173I like their tools like pfctl, raidctl. Hopefully they create something like sslctl.
OpenSSL is a library, not a program like pf.
Re: LibreSSL
#174With close to years of C under my belt, I believe it's a major error, today, to write a critical cryptographic library in C. OK, do the codecs in C if it's the only way to meet performance requirements. But the rest must be written in a language that's reasonably analyzable statically, and with adequate abstractions. Seriously, have you looked at the filthy mess of leaky abstractions that OpenSSL's BIO system is? How…
People might disagree, but why is this downvoted so much?
Re: LibreSSL
#175libressl.org is inaccessible via ssl - is it some kind of irony or something?
Why would they need that for a temporary web page? And one that has no need to be accessed via ssl? They threw together a page to give you some information and that is all.
Re: LibreSSL
#176I may have a stupid question but... While I really enjoy Theo's talks and writings, I wonder if the fact that the VCS is CVS ain't a security issue in itself? It's been really a long time I haven't used CVS but I remember that attempt to introduce backdoors in projects using Git as a (D)VCS have been caught (it was in the Linux kernel I think). IIRC some attempts were caught precisely because it's hard to fake SHA ha…
Git uses SHA-1 hashes, which have not been considered cryptographically secure since 2005. Git and CVS are both just tools. They each provide a server implementation, but it's uncommon to use either of these for write access in large projects. It's more common to wrap CVS or Git with a different frontend like HTTPS or SSH. My guess is that the OpenBSD guys use OpenSSH. This team is fanatical about security and proces…
SHA-1 has been shown to not be collision-resistant. Correct me if you've heard otherwise, but I believe SHA-1 is still believed to be second-preimage resistant.
In other words, with fewer than 2 * * 80 trials, an attacker can generate two files that have the same SHA-1 hash. (In the case of C source files, this probably means embedding a nonsense comment in the middle of each file, probably several hundred to several thousand ASCII characters.) If an attacker can get the very carefully constructed benign file past code review and have the ability to modify the repository, they can substitute the very carefully crafted malicious file for the very carefully crafted benign file without changing the root of the Merkle tree.
Assuming that SHA-1 is still second-preimage resistant, it will take an attacker about 2 * * 159 attempts to come up with a file that has the same hash as a legitimate file not carefully constructed by the attacker.
So, the weaknesses in SHA-1 probably mean that exploiting those weaknesses in the context of git still requires a mole in the development team. Though, I wouldn't want to bet my life on nobody noticing a big nonsense comment in the middle of a C file or someone figuring out how to construct a reasonably reviewable C file as the carefully crafted benign file.
In any case, the weaknesses in SHA-1 still likely pose a significant difficulty in forging a git history without planting a mole in the dev team. It's much better than no cryptographic barriers to forgery.
Re: LibreSSL
#177It's indeed a great effort. Lets just hope that it delivers what is promising and doesn't bring other sorts of vulnerabilities due to the new implementation/code.
I, for one, would be extremely surprised if that happened. They are very thorough (even considering incomplete docs as a bug to be fixed).
Re: LibreSSL
#178Earlier quoted context omitted.
Agreed. This is a bit scary. I feel the resources would be better off focusing on merging with the official OpenSSL project rather than forking and _then_ asking for funding, essentially taking any potential funding from the official OpenSSL project.
I get your point, but let's face it, the OpenBSD developers have done more to fix OpenSSL in the last two weeks that the OpenSSL developers done the last two years. Some of the bug fixes have been pull from OpenSSLs bugtracker, they've just sat there for one or two years. This should make you think about what motivates the OpenSSL developers, my guess would be new crypto algorithms and the math, rather than maintaini…
> the OpenBSD developers have done more to fix OpenSSL in the last two weeks that the OpenSSL developers done the last two years.
> one doubts that the OpenSSL developer understand the math and crypto in SSL and TLS, but they aren't the sharpest C programmers
I think you're selling them way too short!
Re: LibreSSL
#179> removed MacOS, Netware, OS/2, VMS and Windows build machinery What are the plans for native Windows support? I don't know what they mean by "The right Portability team in place", but it'd be a joke if the lib would require CygWin or some other external portability scaffolding. And without proper Windows support LibreSSL will simply fragment OpenSSL user base. I guess it's still better than nothing, but it definitel…
maybe it's better to switch to NSS, the original SSL library developed by Netscape (now by Mozilla, Google, etc.), that is available under better open source licenses, is used in Firefox, (Chrome), OpenOffice, etc. and has an optional compatible API to OpenSSL: http://en.wikipedia.org/wiki/Network_Security_Services
Last I looked, libnss still relied on libnspr, which brings it's own amount of overhead.
Re: LibreSSL
#180Earlier quoted context omitted.
They're making a fork of OpenSSL, and removing all the cruft. Porting it to a completely different language would be an error. There are several alternatives to OpenSSL available and/or popping up right now. They might or might not be a better choice for new developments. But refactoring OpenSSL (where a lot of currently used software depends upon) is certainly not a dumb decision.
Agreed, there's no realistic way to port OpenSSL to a new language. What I'm saying is, I think a clean-up fork of OpenSSL will divide the workforce per project, without dramatically improving security. So it's not "dumb", but I expect the net result to be negative. At least a clean reimplementation featuring XXI-th century technologies would have a non-zero chance to produce something great.
I don't agree at all. I am betting that once LibreSSL is "done" it will get adopted heavily and the community will have a cleaner and more secure code base to work from going forward.