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

101–110 of 112 posts

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

#101

Post by teddyh »

mcpherrinm wrote: post #96
teddyh wrote: post #94

Earlier quoted context omitted.

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

That seems like a bit of circular reasoning.

We use RFC 6091 because it’s the best fit for our problem, and allows us to avoid the needless complexity of X.509 certificates, which has caused many bugs in the past (in essentially all TLS libraries).

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

#102

Post by gkya »

smt88 wrote: post #99
gkya wrote: post #97

Earlier quoted context omitted.

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

Related reading: https://tonyarcieri.com/would-rust-have-prevented-heartbleed...

Ted comments on this post in the article that it critiques. I do know that rust has important tools for writing secure programmes but using them is not really enforced (ie unsafe {}), thus it's possible to write exploitable bug in it. I want to note that I never used it though.

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

#103

Post by fridsun »

gkya wrote: post #102
smt88 wrote: post #99

Earlier quoted context omitted.

Related reading: https://tonyarcieri.com/would-rust-have-prevented-heartbleed...

Ted comments on this post in the article that it critiques. I do know that rust has important tools for writing secure programmes but using them is not really enforced (ie unsafe {}), thus it's possible to write exploitable bug in it. I want to note that I never used it though.

In the end it's possible in any language to produce exploitable bug (apart from maybe Erlang VM?). The point is about 1) how hard (probable) it is, 2) how popular are error checking tools (C static analyzers, Google Thread Sanitizer, etc), and 3) how fast can the culprit code be found and fixed.

In that regard Rust has reduced both 1) and 3) by only exposing dangerous features in unsafe {}, and greatly improved 2) since the compiler itself is checking those errors.

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

#104

Post by tristor »

> The following things are broken, obsolete, badly designed, underspecified, dangerous and/or insane. Rustls does not support:

> Client authentication.

> Kerberos.

From a complexity perspective I understand why these things would not be the first choice to implement in a new library. What I don't understand is why they're on the "will never implement" list. Public-key client authentication is to this day one of the strongest methods of authentication that can be used, and not having that available in a library greatly limits its usages in high-security applications, exactly the places where someone might want to stop using OpenSSL and its broken peers.

Kerberos... well... Kerberos is a cluster-fuck. I think everyone knows that. But there are specific applications where Kerberos (or something similar) is exceptionally useful and maybe even necessary. I will acknowledge though that if Kerberos is missing its not a world-ender, because you can implement your own token-based authentication on top of normal TLS without using Kerberos, which in some cases might even be easier because Kerberos is a cluster-fuck. Despite this, though, if configured properly Kerberos is still one of the best methods for doing secure authentication between multiple servers/services via a central authentication mechanism.

If the justification here is simply implementation complexity that might cloud the codebase or otherwise make it harder to audit for security, I do understand that reasoning. I'm just curious specifically in these two cases because they stood out from the list as things that I don't consider "insane", unlike most of the rest of the list.

As an aside, thanks for not implementing RC4. RC4 needs to die die die die. I don't know why anyone is still using it, but nonetheless I see it in the wild still sometimes :(

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

#105

Post by rectang »

oconnore wrote: post #4

I'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.

Likewise. "Modern" is a worthless word. In time, the flaws of any "modern" product will become apparent and it will be replaced by something more "modern".

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

#106

Post by [deleted] »

tristor wrote: post #104

> The following things are broken, obsolete, badly designed, underspecified, dangerous and/or insane. Rustls does not support: > Client authentication. > Kerberos. From a complexity perspective I understand why these things would not be the first choice to implement in a new library. What I don't understand is why they're on the "will never implement" list. Public-key client authentication is to this day one of the s…

[deleted]

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

#107

Post by edraferi »

jeffdavis wrote: post #95
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?

Is that still true in MirageOS, which runs as a Unikernel on top of Xen?

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

#108

Post by e12e »

rurban wrote: post #63
oconnore wrote: post #4

I'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.

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…

I think Shakespeare got this one right:

  2. New and common; trite; commonplace. [Obs.]
     [1913 Webster]
  
     We have our philosophical persons, to make modern
     and familiar, things supernatural and causeless.
                                               --Shak.
Isn't that what we want from "modern" software? To "make modern and familiar" "things supernatural and causeless"? :-)

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

#109

Post by e12e »

tristor wrote: post #104

> The following things are broken, obsolete, badly designed, underspecified, dangerous and/or insane. Rustls does not support: > Client authentication. > Kerberos. From a complexity perspective I understand why these things would not be the first choice to implement in a new library. What I don't understand is why they're on the "will never implement" list. Public-key client authentication is to this day one of the s…

Odd to see "PSK" on the possible future feature list, with "client authentication" on the "never" list.

Other than that, looks like a nice and sane subset they've picked.

Real shame if they end up avoiding cert-based authentication, though. All other options for authentication are strictly worse, from a security perspective - and leaves more room for implementors to shoot themselves in the foot. For passwords that are intended for human users, for example, you really need some form of rate-limiting. Not to mention the problem of setting up a session first, and then later binding to a user (if authentication succeeds) rather than the simpler "only valid client can connect".

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

#110

Post by nickpsecurity »

eatonphil wrote: post #92
nickpsecurity wrote: post #87

Earlier quoted context omitted.

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.

Sure thing. :) And here's the OpenVMS & Windows connection in case you weren't aware of it:

http://windowsitpro.com/windows-client/windows-nt-and-vms-re...

Bill robbing Apple of GUI is well-known. Less known is he stole a more robust and secure architecture from OpenVMS that was most rock-solid of OS's. They managed to show what would happen if OpenVMS had no QA process during development. Yet, recent efforts have gotten Windows Server reliable enough that the connection is more believable. :)

Post reply on HN