Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LibreSSL

libressl.org

Post reply on HN
Print view View original

221–230 of 262 posts

Re: LibreSSL

#221

Post by q3k »

TacticalCoder wrote: post #145

I 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…

As far as I read up about this some time ago, it boils down to the following reasons:

- CVS is simple - it's small (fits on a floppy with bsd.rd) and easy to use on exotic/slow architectures - CVS is preferable for their current contribution workflow (centralized) - CVS is treated as a tool that, currently, just works (tm)

Re: LibreSSL

#222

Post by deegles »

sigzero wrote: post #180
fab13n wrote: post #157

Earlier quoted context omitted.

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.

I trust the OpenBSD team to get it right.

Re: LibreSSL

#223

Post by teacup50 »

abcd_f wrote: post #34

> 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…

Most (all?) native Windows applications shouldn't use OpenSSL.

They should use the operating system-shipped APIs, along with the OS-shipped certificate stores.

That means SChannel and CryptoAPIs in native code.

Re: LibreSSL

#224

Post by teacup50 »

abcd_f wrote: post #41
bananas wrote: post #36

Earlier quoted context omitted.

Probably none. Windows has its own CSP library which is a little more convenient in a win32 context than OpenSSL or anything POSIX TBH. I think they're doing the right thing here.

There's a ton of Windows software that uses OpenSSL as their security library. Moreover, there is a lot of Windows projects that are written in inherently portable way and using OpenSSL API is the most natural choice for them. If StartSSL manages to topple OpenSSL and to discourage any further OpenSSL development, then that'd be a very bad thing for a lot developers.

> There's a ton of Windows software that uses OpenSSL as their security library.

Yes, and most of it is awful because they shouldn't. I hate manually configuring SSL certificates for OpenSSL-using Windows software.

Write a socket transport portability layer. It's not that hard, and you almost certainly need one anyway.

Re: LibreSSL

#226

Post by nfoz »

antocv wrote: post #138
mrweasel wrote: post #70

Earlier quoted context omitted.

Why are people so obsessed with getting the OpenBSD developers to move from CVS? If it works for them and do what they need there's no need to move.

For security reasons. It is possible with CVS and even SVN to insert bad code on their repository server - but with git thats a much harder if not impossible to do.

Can you explain how this attack works, or provide a link?

Re: LibreSSL

#227

Post by carussell »

hsivonen wrote: post #204
gpcz wrote: post #183

I've been thinking recently about Heartbleed, and I was wondering if by writing C code to implement various network and cryptographic protocols, we're acting as human compilers for something that might be better represented in a more abstract format. I know there's some research on this already (the Austin Protocol Compiler), but does anyone here know of any other serious efforts to take the human out of the equation…

Rust ( http://www.rust-lang.org/ ) is a serious effort to build a language that's close to metal like C but safe.

I think gpcz was suggesting something more along the lines of an entirely new approach to protocol implementation, like VPRI's TCP/IP stack that Jeff Moser describes[1], rather than just swapping out C for something else while keeping the hand-written aspect.

> Let's say we want to build the TCP/IP stack of an operating system. A traditional implementation might take 10,000 lines of code. What if you rethought the design from the ground up? What if you could make the IP packet handling code look almost identical to the RFC 791 diagram which defines IP?

If the industry as whole could agree on this approach in a move similar to the Dijkstra/structured programming move that happened a few decades back, the sort of verifiable interoperability + security that Meredith Patterson and Sergey Bratus (who you may recognize from Occupy Babel![2]) call for would be closer to reach[3].

1. Jeff Moser. Towards Moore's Law Software: Part 3 of 3. https://www.youtube.com/watch?v=UzjfeFJJseU

2. Occupy Babel!. http://www.cs.dartmouth.edu/~sergey/langsec/occupy/

3. Meredith Patterson. LANGSEC 2011–2016. https://www.youtube.com/watch?v=UzjfeFJJseU

Re: LibreSSL

#228

Post by afiler »

q3k wrote: post #221
TacticalCoder wrote: post #145

I 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…

As far as I read up about this some time ago, it boils down to the following reasons: - CVS is simple - it's small (fits on a floppy with bsd.rd) and easy to use on exotic/slow architectures - CVS is preferable for their current contribution workflow (centralized) - CVS is treated as a tool that, currently, just works (tm)

It seems ever-so-slightly ironic that support for exotic architectures is considered a plus in this case, while support for exotic architectures is being ripped out of the OpenSSL/LibreSSL codebase. (Though probably not deeply ironic, since CVS is comparatively simple.)

Re: LibreSSL

#229

Post by peterwwillis »

fab13n wrote: post #157
dtech wrote: post #142

Earlier 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.

> At least a clean reimplementation featuring XXI-th century technologies would have a non-zero chance to produce something great

There are no guarantees of anything working out or being great, regardless of technology. And whatever language/tech you use would require a couple of layers of control. For example, ensuring the low-level features of the language don't betray entropy to statistical analysis, or managing (and ensuring) the virtual memory used is cleaned up properly, or being as efficient as possible lest the crypto become a performance barrier to use.

It's not like high level languages can't implement crypto as well as lower level ones; they can. But it's a lot easier to ensure the various attack vectors are mitigated in a low-level language where there's no glue [outside of that included in your source] to get in the way, obscure, or otherwise subvert the security and performance of the applications using your code. The Heartbleed bug happened because the glue they chose to use was crappy; this was an implementation problem, not a low-level-language problem.

Re: LibreSSL

#230

Post by worr »

higherpurpose wrote: post #127
CHY872 wrote: post #116

Earlier quoted context omitted.

No. It needs corporate involvement, from Google, Red Hat, Amazon, Verisign etc. Lend minds, not money. By all means fund people to write it, but like it's not you who should be contributing, it's the corporations who rely on it.

Google and Amazon should be donating to LibreSSL, too. They may have no intention of using it in the next few years, but I'm sure they'd like for a solid alternative to be out there, so they can use it just in case they do change their minds, just like Google recently did with the switch from NSS to OpenSSL, just before Heartbleed happened. It would've been smart of them to donate to OpenSSL starting a few years back…

Google already donates to LibreSSL; they annually donate to OpenBSD. That money goes towards projects like LibreSSL.
Post reply on HN