OpenBSD Journal

a2k17 hackathon report: Bob Beck on LibreSSL progress and more

Contributed by pitrh on from the puffy hugged a dropbear dept.

Fresh from the newly completed a2k17 hackathon comes this report from Bob Beck:

So, I wasn't going to do this one, but I had enough fun sitting next to jsing@ in Toulouse in November working on LibreSSL, I did a bunch of stuff this time:
  1. I went through LibreSSL and attacked all the constant time functions in the bignum library, and changed these functions as used internally to always use the safe constant time mode of operation, to somewhat mitigate timing attacks.

  2. jsing@ and I bumped the LibreSSL majors and started moving a lot of the bits out of the SSL/TLS structures into private locations, removing publicly accessible API that is not used (or should not be used unless you are a crack addled rhesus monkey) We are still dealing with the ports fallout (ensuring that most ports still build) and we have had to move a few things back that we got too aggressive with, but largely this has been a success and will let us move forward at unifying more of the libssl code to make our lives easier going forward (I'll let jsing@ talk about that.)

  3. I did a bunch of fixes to ftp, as well as the ftp cgi's on www.openbsd.org used by the installer to support TLS in the installer and new awesomeness to be done by rpe@.

  4. I wrote and committed ocspcheck(8) so we have a command in base to use for OCSP stapling on servers, replacing the need to use a lot of nasty "openssl x509' and 'openssl ocsp' to accomplish the same thing.

Thanks very much to dlg@ jono, and the University of Queensland for hosting! it was very productive

Thanks for the report, Bob! Judging from recent commits, other devs will be queueing up with interesting reports over the next few days too, and we're looking forward to hearing from them all.

(Comments are closed)


  1. By Etienne (2400:cb00:25:10e::1) on

    From ocspcheck's manpage:

    While ocspcheck could possibly be used in scripts to query responders for server certificates seen on client connections, this is almost always a bad idea. God kills a kitten every time you make an OCSP query from the client side of a TLS connection.

    I'm really unsure what the problem is with that. It seems to me that it's exactly what OCSP was meant for? Can anyone explain?

    1. By Chas (142.79.57.1) on

      > I'm really unsure what the problem is with that. It seems to me that it's exactly what OCSP was meant for? Can anyone explain?

      As I prefer to use stunnel for most TLS (which doesn't yet support OCSP stapling), it's certainly a price that I'm willing to pay. Privilege separation in a chroot is simply a better policy.

      The cost is added OCSP/CRL hassle between the clients and the CA, but I generally don't admin those, so it's not a high priority for me.

    2. By nahun (2601:602:9400:e12b:8cc5:fbe3:1844:bef) on

      > From ocspcheck's manpage:
      >
      > While ocspcheck could possibly be used in scripts to query responders for server certificates seen on client connections, this is almost always a bad idea. God kills a kitten every time you make an OCSP query from the client side of a TLS connection.
      >
      > I'm really unsure what the problem is with that. It seems to me that it's exactly what OCSP was meant for? Can anyone explain?

      I'm pretty sure it means making an OCSP query from the SERVER side for each TLS connection is fine, but not from the client side. Server side seems normal in my experience. I'm not sure how much OCSP is used on clients to confirm server certs, I've only used it in client certificate authentications.

    3. By Philip Guenther (76.253.1.113) on

      > From ocspcheck's manpage:
      >
      > While ocspcheck could possibly be used in scripts to query responders for server certificates seen on client connections, this is almost always a bad idea. God kills a kitten every time you make an OCSP query from the client side of a TLS connection.
      >
      > I'm really unsure what the problem is with that. It seems to me that it's exactly what OCSP was meant for? Can anyone explain?

      Doing OCSP from the client means you're also dependent on connectivity to the OCSP server, which was quite poor in empirical tests done by Google using backend queries by Chrome.

      Instead, the recommended approach is to have the server do the OCSP query and 'staple' the sufficiently fresh response into the TLS handshake to clients after that via a TLS extension sent by the server to the client.

  2. By Chas (142.79.57.1) on

    It would be really nice if the portable LibreSSL bundled ftpd. I'm occasionally asked for ftps, and I point out the stern warning from the vsftpd manpage.

    There are many who despise the protocol for it's ambiguities who would be displeased by such a move, but a whole ftps stack with OpenBSD code quality would be quite useful in dealing with an OS2200 system that occasionally troubles me.

    ssl_enable
    If enabled, and vsftpd was compiled against OpenSSL, vsftpd will
    support  secure connections via SSL. This applies to the control
    connection (including login) and also data  connections.  You'll
    need a client with SSL support too. NOTE!!  Beware enabling this
    option. Only enable it if you need it. vsftpd can make no  guar‐
    antees  about the security of the OpenSSL libraries. By enabling
    this option, you are declaring that you trust  the  security  of
    your installed OpenSSL library.
    
    Default: NO

    1. By George Koehler (kernigh) on

      > It would be really nice if the portable LibreSSL bundled ftpd.

      The base tools in OpenBSD don't do FTP over TLS. The ftpd(8) manual doesn't mention TLS; the ftp(1) client only uses TLS with HTTPS, not FTP.

      1. By Chas (142.79.57.1) on

        > The base tools in OpenBSD don't do FTP over TLS. The ftpd(8) manual doesn't mention TLS; the ftp(1) client only uses TLS with HTTPS, not FTP.


        I've never tried to use this. I should give it a whirl.


        https://www.openbsd.org/papers/libtls-fsec-2015/

        Current libtls API users:

        ftpd, nc, ntpd, httpd, spamd, syslog in OpenBSD

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]