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

Rustls: new, modern TLS library written in Rust

github.com

Post reply on HN
Print view View original

81–90 of 112 posts

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

#81

Post by eatonphil »

briansmith wrote: post #46
nialv7 wrote: post #39

Rustls use ring for crypto, and it seems most of the crypto algorithm code of ring is written in C/assembly. Kind of destroy the purpose?

Hi, I'm the person who started the ring project. There is a lot of assembly language code in ring , and there's still some C code too. The thing to keep in mind is that we started from 100% C and assembly language code. Since August 2015, ring has supported a 100% Rust certificate validation library (webpki, it's open source on GitHub), and a 100% Rust TLS implementation (not Rustls, but one that wasn't open source).…

Thanks for taking the time to write this detailed summary. Ring is quite an impressive project.

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

#82

Post by muflax »

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…

Perl is explicitly postmodern. Here's Larry Wall explaining it: http://www.wall.org/~larry/pm.html

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

#83

Post by cmrdporcupine »

vxNsr wrote: post #67
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…

You've given a while bunch of definitions for what you interpret modern to mean but none of those are inherent in the word which is what (I think) the op meant when complaining about its over usage. So while I appreciate your attempt to redefine "modern" with all the above I'd rather people just used the more verbose explanation instead of using the meaningless term.

He's not redefining the term, he's giving the 'official' definition of modern from the humanities.

The word has spread in popular vernacular to mean 'the present' or 'contemporary' but for historians, philosophers, architects, art critics, critical theorists, etc. "modern" refers to a bunch of things, and the "modern era" is considered by many of them to be either over, extended, or exaggerated.

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

#84

Post by nickpsecurity »

hannob wrote: post #73
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

Neither ocaml-tls nor this new one do formal verification. The only TLS library that does so is miTLS.

Let's not forget the security kernel in Guttman's cryptlib. It's like a lightweight variant of formal verification that justs makes sure things interface correctly.

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

#85

Post by thristian »

mcpherrinm wrote: post #47
colemickens wrote: post #44

Earlier quoted context omitted.

What does Rust the language have to provide in order to achieve side channel resistant algorithms? That doesn't sound right to me. There are primitives in other languages that are needed? Or Rust doesn't abstract at the right level? edit: thanks for the explanations!

Ultimately, it's an optimizing compiler, and it's difficult/impossible to tell the compiler "make this code fast, but not too fast for these specific cases". The same problem affects basically every language that isn't assembly.

It might even affect assembly, if your CPU's microcode optimizations are sufficiently aggressive.

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

#86

Post by frutiger »

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.

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

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

#87

Post by nickpsecurity »

eatonphil wrote: post #80
bogomipz wrote: post #74

Earlier quoted context omitted.

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…

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 existing for a long time.

So, who won? Nobody. Both had success. Most successful, though, was combining a little bit of MIT method, cathedral, and ship fast from "worse is better." That's IBM and Microsoft's approach. A hybrid worthy of another Gabriel essay.

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

#88

Post by kalkin »

ctz wrote: post #57
johncolanduoni wrote: post #12

Earlier quoted context omitted.

I'd love to see an explanation for not supporting client authentication. Also, completely ruling out discrete-log DH and requiring PFS is not feasible unless you want to rule out a lot of clients and servers, on top of not supporting TLS 1.1.

There's a few problems with it. 1. client auth in TLS1.2 and earlier is done at the wrong time in the handshake. As a result the client's identity (which unlike the server identity usually identifies a user; see sibling comment which confirms this) is sent in the clear. That's a big privacy failure. 2. to work around (1), some implementations do an initial server-auth handshake, then immediately renegotiate up to mut…

Super nitpicky, but would it make sense in the README then to specify "client authentication per TLS 1.2 or earlier", as the non-feature, or something like that?

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

#89

Post by nickpsecurity »

briansmith wrote: post #27
Manishearth wrote: post #22

Earlier quoted context omitted.

Probably not. With security sensitive things, the security of the logic itself needs to be good too. Attacks like downgrade attacks, for example, are not memory unsafety issues. Servo would need a library that is battle-tested and has a vulnerability policy. The Rust libraries could be in this category in the future, but not right now. Using something like nss or boringssl, like other browsers, would be our best bet.

> Attacks like downgrade attacks, for example, are not memory unsafety issues. First, this library only implements TLS 1.2 with AEAD cipher suites (AES-128-GCM, AES-256-GCM, and ChaCha20-Poly1305) and perfect forward secrecy (using ECDHE with the X25519, P-256, and P-384 curves, and RSA and ECDSA signatures). Thus, downgrade to something worse than what NSS or OpenSSL or BoringSSL consider to be the very best crypto…

Despite that, Manishearth is correct that they should rely on a battle-tested library instead of just Rust. That's just one kind of issue. The main ones will be:

1. Abstraction gap issues where security analysis of algorithm/protocol didn't reflect a realistic implementation. Padding errors were an old example of that.

2. Issues with each individual component where it might have not been instantiated or removed correctly.

3. Interface errors where things were connected in a dangerous way. Examples include wrong ordering or meet-in-middle.

4. Parsing errors.

5. Memory safety issues.

6. Compiler optimizations introducing security issues or removing security checks.

7. Covert storage or timing channels. Mainstream INFOSEC have re-discovered them as "side channels." I'm not sure you can even do covert, channel analysis in Rust yet as it requires a clear mapping from language to assembler. Most projects just ignore this requirement although BoringSSL addresses it with hand-coded assembly as you pointed out.

So, there's a lot of ground to cover implementing even a straight-forward, crypto protocol to ensure it's secure. Most of that has nothing to do with the protections Rust offers. Matter of fact, it might be a step back in many ways due to immature (or non-existent) tooling for specific requirements on the list. Side-by-side SPARK and MISRA C implementations with design-by-contract and some assembly are the strongest here for now.

Keep at your project, though. Your longer comment detailing the work was quite impressive. Great work. Even better that you're gradually tweaking one that already works in real-world deployments. Will avoid many issues that way.

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

#90

Post by strmpnk »

hannob wrote: post #73
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

Neither ocaml-tls nor this new one do formal verification. The only TLS library that does so is miTLS.

Which is interating here since F* can extract to OCaml. I wonder how hard it would be to wire up a test harness to compare the two with randomized tests.
Post reply on HN