Rustls: new, modern TLS library written in Rust • Hacker News Board

Re: Rustls: new, modern TLS library written in Rust

#91

Post by nickpsecurity » Sun, Jul 10, 2016, 3:00 PM UTC

nialv7 wrote: post #77

mtgx wrote: post #54

Earlier quoted context omitted.

It's also an argument against disruption in general. Great progress happens when people stop iterating and start rethinking stuff that hasn't been rethought for decades (and the "stuff" has seen only tiny improvements over the years following this strategy, too).

Don't get me wrong, I'm not against disruption at all. It's just there're cases where doing this doesn't make sense. Write a new text editor, invent a new programming language, sure. But writing a new cryptography library? You are throwing away decades of effort that went into to harden and secure the existing library, and your gain is pretty small. Making things even worse is that you can't really write a crypto lib…

"You are throwing away decades of effort that went into to harden and secure the existing library, and your gain is pretty small."

If that were true, then it would be a good counterpoint worthy of long thought. The reality of crypto libraries is that popular ones often had preventable errors due to bad coding and/or unsafe language that also took entirely too long to notice.

"you can't really write a crypto library without using C/assembly"

I'd argue you can't write a crypto library using C by default unless you're a really good coder. C is just an accident of two team's bad hardware:

http://pastebin.com/UAQaWuWG

Languages like Modula-3, Free Pascal, and even Fortran were easier to analyze to ascertain the program's properties. It's why Modula-3 had first, standard library verified free of specific types of errors. Also took years to make a certified compiler for C which had been done in other, simpler languages. Finally, the top performer in secure, systems code is SPARK as illustrated when re-implementing C crypto in it caught a problem.

http://www.adacore.com/press/spark-skein/

Note: The portability result was also impressive given it's one of C's strengths and difficulties.

Re: Rustls: new, modern TLS library written in Rust

#92

Post by eatonphil » Sun, Jul 10, 2016, 3:15 PM UTC

nickpsecurity wrote: post #87

eatonphil wrote: post #80

Earlier quoted context omitted.

Look into "New Jersey vs. MIT" and "worse is better". The idea more or less is that AT&T (in Jersey) cared more about software that shipped whereas MIT cared about more about good design. MIT produced Lisp and Lisp machines, Bell Labs produced C and Unix. Who won?

The mainframes and OpenVMS (though its clone, Windows). They're produced closer to the MIT and cathedral styles with a practical focus. The mainframes still run the backends of our financial system, logistics, big retailers, and so on. Most stuff that people consume requires one of them. If a desktop is involved, it's usually Windows based with 90+% of the market share despite UNIX workstations and Linux desktops exi…

Thanks for the additional perspective there. I'll have to keep that in mind.

Re: Rustls: new, modern TLS library written in Rust

#93

Post by houli » Sun, Jul 10, 2016, 3:56 PM UTC

bogomipz wrote: post #74

rurban wrote: post #63

Earlier quoted context omitted.

It does. There are distinct properties attached to Modernism and Modern. (I'm architect, hence I'm very much attached to these terms. Unlike SW people who didn't grow up with that). First of all, it's the opposite of Post-Modern, to the perl style do it all in myriads of ways, everything is allowed, OpenSSL style. With Modern, only the best API and implementation is allowed. API's are Stanford style well-planned ahea…

Why are you conflating building architecture and software architecture. I'm pretty sure no software developer has every thought of their project in terms of "post-modern." New Jersey style? The PERL style? I've never heard of "New Jersey style." Are you joking? I'm almost positive that Perl didn't influence openssl development at all. "Modern is more old Stanford-style development." I think you've read way to much in…

What about all of these Perl scripts generating assembly code for AES for every architecture under the sun? https://github.com/openssl/openssl/tree/master/crypto/aes/as...

Re: Rustls: new, modern TLS library written in Rust

#94

Post by teddyh » Sun, Jul 10, 2016, 4:22 PM UTC

mcpherrinm wrote: post #50

teddyh wrote: post #21

My application needs RFC 6091, i.e. using OpenPGP keys instead of the usual X.509 certificates. (Why not X.509? Ask Peter Gutmann¹). This feature is not listed as something they don’t support, nor as something they won’t support, which is odd. Likewise for DTLS (RFC 6347). These omissions are strange. ① Everything you Never Wanted to Know about PKI but were Forced to Find Out ( https://www.cs.auckland.ac.nz/~pgut001/…

This is exactly the sort of cruft that's quite rarely used and should be omitted from a lean implementation. I'm not aware of any serious use of RFC 6091. GnuTLS supports it, but I don't think any other implementations do.

> I'm not aware of any serious use of RFC 6091.

Was it really your intention to dismiss my application¹ as not serious?

① https://www.recompile.se/mandos

Re: Rustls: new, modern TLS library written in Rust

#95

Post by jeffdavis » Sun, Jul 10, 2016, 4:38 PM UTC

rudenoise wrote: post #59

Can anyone comment on how this implementation of TLS compares to the recent ocaml/mirageOS version? How much does formal verification matter/increase confidence? Is the rust version easier to integrate with other stacks? https://mirage.io/blog/why-ocaml-tls

OCaml has more runtime requirements. Can someone comment on how invasive those requirements are, and whether that would limit adoption of the OCaml version compared with C or rust?

Re: Rustls: new, modern TLS library written in Rust

#96

Post by mcpherrinm » Sun, Jul 10, 2016, 5:13 PM UTC

teddyh wrote: post #94

mcpherrinm wrote: post #50

Earlier quoted context omitted.

This is exactly the sort of cruft that's quite rarely used and should be omitted from a lean implementation. I'm not aware of any serious use of RFC 6091. GnuTLS supports it, but I don't think any other implementations do.

> I'm not aware of any serious use of RFC 6091. Was it really your intention to dismiss my application¹ as not serious? ① https://www.recompile.se/mandos

It may be serious but I wasn't aware of it.

It seems your project could use x509 client certs as well as gpg ones if you wanted to use a different TLS library that didn't support GPG.

Re: Rustls: new, modern TLS library written in Rust

#97

Post by gkya » Sun, Jul 10, 2016, 5:59 PM UTC

progman wrote: post #70

Perceptes wrote: post #38

I'm so happy to see something like this in development. Every time there's a discussion about OpenSSL vulnerabilities, the topic of a future replacement written in Rust comes up, but no one was stepping up to the plate. Now we have some real progress towards a safer future.

There is also Thrussh, a Rust library for SSH. Rust now begins to shine where it was designed for -- in security. According to https://doc.rust-lang.org/book/ffi.html it is possible to make callbacks from C code to Rust functions. This way other languages could take advantage of Rust's safe libraries.

Language having safety features does not guarantee code free of vulnerabilities.

Re: Rustls: new, modern TLS library written in Rust

#98

Post by gkya » Sun, Jul 10, 2016, 6:00 PM UTC

frutiger wrote: post #86

progman wrote: post #70

Earlier quoted context omitted.

There is also Thrussh, a Rust library for SSH. Rust now begins to shine where it was designed for -- in security. According to https://doc.rust-lang.org/book/ffi.html it is possible to make callbacks from C code to Rust functions. This way other languages could take advantage of Rust's safe libraries.

There have been far fewer serious vulnerabilities in OpenSSH than in OpenSSL.

OpenSSL is not from the OpenBSD project whereas OpenSSH is.

Re: Rustls: new, modern TLS library written in Rust

#99

Post by smt88 » Sun, Jul 10, 2016, 6:57 PM UTC

gkya wrote: post #97

progman wrote: post #70

Earlier quoted context omitted.

There is also Thrussh, a Rust library for SSH. Rust now begins to shine where it was designed for -- in security. According to https://doc.rust-lang.org/book/ffi.html it is possible to make callbacks from C code to Rust functions. This way other languages could take advantage of Rust's safe libraries.

Language having safety features does not guarantee code free of vulnerabilities.

Re: Rustls: new, modern TLS library written in Rust

#100

Post by Perceptes » Sun, Jul 10, 2016, 7:35 PM UTC

gkya wrote: post #97

progman wrote: post #70

Earlier quoted context omitted.

There is also Thrussh, a Rust library for SSH. Rust now begins to shine where it was designed for -- in security. According to https://doc.rust-lang.org/book/ffi.html it is possible to make callbacks from C code to Rust functions. This way other languages could take advantage of Rust's safe libraries.

Language having safety features does not guarantee code free of vulnerabilities.

Yes, but I don't think progman was suggesting that. Rust doesn't prevent code from having logic errors, but it does protect you entirely from certain classes of errors (e.g. use-after-free memory violations) as long as you stick to safe Rust. These are some of the most common bugs in C programs which have resulted in highly publicized vulnerabilities, so Rust will take a program a very long way towards being safer than any C counterparts.