21–30 of 112 posts
① Everything you Never Wanted to Know about PKI but were Forced to Find Out (https://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf)
I wonder, will Servo use this?
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.
I wonder, will Servo use this?
I wonder, will Servo use this?
Earlier 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.
My guess? They don't use it in their applications, so they don't think anyone else uses it, either.
TLS client authentication is widely used in 802.1X (WiFi and wired) authentication. I've seen it used in a lot of other situations, e.g. web client access (client cert + user password), LDAP client access, etc.
Maybe there are security issues in client authentication which they're aware of. If so, they should share them. But simply labeling client authentication as "obsolete" shows a close-minded attitude.
Earlier quoted context omitted.
I've never even heard of client authentication until recently. That's probably why.
Obscure is not on the list in GP's quote, and afaik client authentication is none of the things in that list. It's actually used a fair bit in uses of TLS that are not the open web.
I wonder, will Servo use this?
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.
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 is avoided at a very fundamental level.
Second, I and other people have been advocating strongly against design decisions that force implementations to add downgrade vectors. In particular, there is a version number field in the TLS ClientHello that we know causes problems. People have proposed solutions to avoid this version number causing compatibility problems for TLS 1.3, but Mozilla's TLS people have not supported making this improvement. Thus, we're likely going to have downgrade issues by design in TLS 1.3 that would be completely avoidable, due in large part to the people making NSS and other C crypto libraries.
Earlier 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.
Client auth is simple to use - our internal services are given the username from the CN, which they use to perform authorization checks. For a lot of simple internal services that don't require two-factor auth it works great.
Am I missing something better?
(We already have the infrastructure in place to deal with client keys)
No support for TLS 1.3? Any reason for this, other than work?
It's listed in the "Possible future features" section... Isn't TLS 1.3 currently still a draft? [1] [1]: https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1...
I think BoringSSL is also[3] working on their implementation and NSS (Firefox's SSL/TLS library) implemented[4] draft 11 in v3.23, but OpenSSL doesn't have plans to until after 1.1 ships[5]; I've heard the former is expected to land about 6 months prior to the latter as OpenSSL isn't starting until the RFC is finalized.
1 - https://tools.ietf.org/html/draft-ietf-tls-tls13-11 (draft 13) 2 - https://nightly.mozilla.org/ 3 - https://www.imperialviolet.org/2015/10/17/boringssl.html 4 - https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NS... 5 - https://www.openssl.org/policies/roadmap.html
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…
It's a tradeoff.