6 ms·
Libtls – New TLS API from LibreSSL
- cremno 12y agoThis isn't a standalone implementation (yet [1]). It's a sane wrapper around OpenSSL's less sane libssl API. [1] https://marc.info/?l=openbsd-tech&m=141524972826918&w=2 https://marc.info/?l=openbsd-tech&m=141524972826918&w=2
- nly 12y agoSource code: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libtls/ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libtls/
- jfindley 12y agoNonetheless - for actually writing code using TLS, it's massively better than navigating the wilds of libssl. Having a full standalone implementation would be even better, but this is still great as-is.
- nly 12y agoDo the defaults strike the best balance between security, PFS and compatibility? Because I think that's really the problem with the TLS libraries I've used, and introducing a new API is a good opportunity to fix that. What happens, for example, if I don't call tls_config_set_ciphers()?
- dicroce 12y agoThat looks very nice.
- parley 12y agoPlease correct me if I'm wrong, but I believe that the OpenSSL API allows one to implement the actual transport of the TLS protected data however one chooses, although it provides convenient socket/fd transports. Is this a possibility with this new API? Regardless of whether OpenSSL can do it today, I consider this a very valuable feature and allows for more flexible composition of the TLS implementation and the rest of the system. Edit: Grammar.
- spand 12y agoFrom the link: * tls_connect() connects a client context to the server named by host. The port may be numeric or a service name. If it is NULL then a host of the format "hostname:port" is permitted. * tls_connect_fds() connects a client context to a pair of existing file descriptors. * tls_connect_socket() connects a client context to an already established socket connection.
- parley 12y agoI did read the linked page, but perhaps I'm misunderstanding something. To me, this looks like it still requires sockets or fds. I want to be able to grab the TLS-protected byte stream conveniently and transport it to the other endpoint however I see fit. This would make it possible to use this TLS implementation easier on top of I/O-frameworks that don't necessarily map immediately down to sockets/fds. Again, for improved composability and code reuse.
- spand 12y agoI believe so too. It seems like a reasonable security tradeoff to limit the kinds of bugs that will be the result of such flexibility.
- parley 12y ago> I believe so too. That sounds strange, as I believe we're in disagreement. I believe the flexibility should exist, and choosing the transport medium of already encrypted data should be an option for the developer. This is completely unrelated to the security critical configuration of the TLS protocol, i.e. certs, keys, ciphersuites, etc.
- tankenmate 12y agoIt is very much a kluge but you can use pipe(2); it will give you two fds both of which you control. Then you can read/write from the "local" end and serialise the traffic however you wish.
- rlpb 12y agoHow does one poll for socket activity using this API, given that a read on a socket doesn't necessarily mean that decrypted data is available, and yet that socket writes may be required?
- vog 12y agoTo better understand the basic reasoning behind this API, I recommend to read the last section ("ressl") of: "LibreSSL: More Than 30 Days Later" http://www.openbsd.org/papers/eurobsdcon2014-libressl.html http://www.openbsd.org/papers/eurobsdcon2014-libressl.html
- xiphias 12y agoHere's the important part: The ressl API does provide one noteworthy feature. Hostname verification. In order to make a secure TLS connection, you must do two things. Validate the certificate and its trust chain. Then verify that the hostname in the cert matches the hostname you've connected to. Lots of people don't do the latter because OpenSSL doesn't do that latter. You have to do it yourself, which requires knowing about things like CommonNames and SubjectAltNames. The good news is that popular bindings for languages like python and ruby include a function to verify the hostname. The bad news is if you pick a python or ruby project at random, they probably forget to do it. Another funny fact is that since everybody has to write this code themselves, everybody does it a little bit differently. Especially regarding handling of wildcard certificates and everybody's favorite, embedded nul bytes. Hostname verification is on by default in ressl, and the API is designed so that you always provide a hostname; there's no way to accidentally call the function that doesn't do verification.
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- alexchamberlain 12y agoNot sure the trade off line has been drawn in the correct place here. TLS should be implemented as a filter; the world isn't limited to files and (blocking) sockets. What about integration with event loops, for example? How does one test this API?
- amelius 12y agoIndeed. Functions like tls_connect and tls_connect_fds don't belong at this level. A TLS library should do only TLS, and behave like a black box, from which you pull data and into which you can push data (in a non-blocking way). Mixing in OS-related stuff only complicates the API.
- wereHamster 12y ago1) Optimizing for the most common use case. 2) You can create file descriptors not backed by any actual network connection or file on the harddrive (man 2 pipe and man 2 socketpair), you can still build an API on top of that which operates purely on buffers.
- amelius 12y ago> 1) Optimizing for the most common use case My compiler is most commonly used together with an editor. Still I'm glad it didn't come with an editor built-in :) > 2) You can create file descriptors not backed by any actual network connection or file on the harddrive Indeed. It doesn't mean it is the preferred way to do it, from a code-quality or even performance point of view.
- zAy0LfpBZLC8mAC 12y agoYes, you can, if your goal is massive bloat. If you want to have reasonable performance and scalability, a blocking API (that is to say, at least one OS thread per connection) and loads of IPC syscall overhead is about the worst thing you could do.
- zzzcpan 12y agoYou are wrong. Blocking socket I/O is rather uncommon in networking software.
- tedunangst 12y agoIt's probably still early to be using this, unless it's of particular interest (interest is encouraged, of course!). There's a reason the server API isn't documented, for example.
- mrweasel 12y agoSo wait until the API is used by relayd, opensmtpd and httpd and see how that works out? I assume that in the end the goal would be to use the libtls for all of the home grown OpenBSD tools?
- tedunangst 12y agoBasically yes. The API evolves as we adapt programs to use it.
- evilpie 12y agoHost and cert verification by default is good. You can use tls_config_set_ciphers to set a cipher string, but I don't see if they disable unsafe ciphers by default.
- teddyh 12y agoOther TLS libraries tend to have an OpenSSL compatibility layer. Now here’s yet another API for them to write compatibility layers for. This is a bad trend. I’m thinking that there ought to be an API defined by an IETF working group and specified in an RFC (like the IPv6 API C interface is), with obvious room for expansion for library-specific features. Then all TLS libraries could implement that API and end the madness. INB4 xkcd 927: https://xkcd.com/927/ https://xkcd.com/927/
- edwintorok 12y agoDoes this API perform OCSP checks?
- zdw 12y agoUnsure of this, but I doubt it. OCSP is generally not a well thought out feature given current attack scenarios: https://www.imperialviolet.org/2014/04/19/revchecking.html https://www.imperialviolet.org/2014/04/19/revchecking.html