Glad to see zero "unsafe" and "panic" :)
Rustls: new, modern TLS library written in Rust
51–60 of 112 posts
Re: Rustls: new, modern TLS library written in Rust
#52I'm developing a twitch whenever I see the word "modern" in a software description. It doesn't actually say anything about what you're doing.
I find that it often seems to be a synonym for "opinionated".
Re: Rustls: new, modern TLS library written in Rust
#53I'm developing a twitch whenever I see the word "modern" in a software description. It doesn't actually say anything about what you're doing.
I'm using 'modern' here in two ways:
- in reference to Mozilla's "Modern TLS" profile: https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_com...
- as an antonym for the unlimited backwards-compatibility, kitchen-sink-comprehensive approach of (say) OpenSSL or NSS.
Re: Rustls: new, modern TLS library written in Rust
#54Memory safety issues are not the only vulnerabilities in a cryptography library. A simple example would be timing attacks. Writing a cryptography library from scratch because the old one has too many security holes? Your implementation is likely to have even more. We should really concentrate on making one implementation secure, instead of creating more libraries.
I hate so much this logic - it stops evolution. Humanity have enough programmers to write new libraries and patch existing code. Competition is better than stagnation.
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).
Re: Rustls: new, modern TLS library written in Rust
#55Memory safety issues are not the only vulnerabilities in a cryptography library. A simple example would be timing attacks. Writing a cryptography library from scratch because the old one has too many security holes? Your implementation is likely to have even more. We should really concentrate on making one implementation secure, instead of creating more libraries.
> Writing a cryptography library from scratch because the old one has too many security holes? Your implementation is likely to have even more.
That's not a reason to never write another crypto library ever. It's a reason to get started on a new one as soon as possible so it can start the process of being vetted.
Re: Rustls: new, modern TLS library written in Rust
#56My 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/…
> ①
Wow, the future is here!
Re: Rustls: new, modern TLS library written in Rust
#57Earlier quoted context omitted.
> The following things are broken, obsolete, badly designed, underspecified, dangerous and/or insane. Rustls does not support [...]
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 mutual-auth (renegotiations are encrypted). Renegotiation has quite a dismal history, and I definitely want to avoid it.
3. as a follow on from (2), the standard never described what implementations are expected to do if client/server identities change during renegotiation. This (partially) resulted in https://mitls.org/pages/attacks/3SHAKE
All of these are fixed in TLS1.3: client identities are encrypted and renegotiation is dropped.
Re: Rustls: new, modern TLS library written in Rust
#58Earlier 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!
Most high-level languages don't provide guaranteed-constant-time behavior at all. That's a big reason why ring uses lots of BoringSSL's/OpenSSL's assembly language code. Also, one of my goals with the ring project is to identify exactly what constant-time utilities are needed for a crypto library, so that I can draft a proposal for improving the Rust language and libraries to provide such features.
> Most high-level languages don't provide guaranteed-constant-time behavior at all.
Does even C provide such guarantees? Isn't the compiler free to rewrite the code it's compiling in whatever way it wishes as long as the output is the same?
Re: Rustls: new, modern TLS library written in Rust
#59Can 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?
Re: Rustls: new, modern TLS library written in Rust
#60Earlier 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…
Yeah, trying to make TLS client identity private is a recipe for sadness (well, before 1.3).
At least in the environments I use TLS, which is interservice datacenter communications, there are no privacy issues (especially since you can just look at what container a connection comes from for the same amount of identity leaking).