Status of OpenSSL 1.1 support - Thoughts

Ingo Schwarze schwarze at usta.de
Thu Oct 19 23:59:02 AEDT 2017


Hi Emmanuel,

Emmanuel Deloget wrote on Thu, Oct 19, 2017 at 01:58:55PM +0200:

> Let's restate the full goal here :
> 
> * first, LibreSSL should integrate the OpenSSL 1.1 API

I believe that is desirable in the long term, and i heard others
talk about it in the past, too, but i won't be the one to make the
decision if and when to do it.

> * second, it should mark the replaced interface as deprecated

That is not required to solve the OpenSSH problem.  At some point,
it may be desirable anyway because in many cases, opaque structs
can be an improvement.

> * third, make OpenSSH use the new interface
> 
> That sounds like a manageable list of goals -- i.e. one that can prove
> to be completed before the EOL of OpenSSL 1.0.2 in Dec. 2019.

In OpenBSD, as a matter of principle, we never promise that some
specific work will be completed by some specific date.  Things
are ready when they are ready: Carefully designed, implemented,
and tested, taking whatever time is needed to do the job properly.

In this specific case, while i do invest signifant time into the
OpenSSL documentation now and then, i cannot order any of my
colleagues around and won't attempt to do so.

> First problem to overcome is that LibreSSL is released every 6 month,
> so the work is probably going to be split on two or more releases.

Not necessarily.  Work on such a task is likely to be started
right after a release, and if restructuring work of such a kind
is started, there is usually an interest to not drag it out over
a very long time, if that is feasible.  No guarantee, obviously.

> As a consequence, the transition work cannot start on OpenSSH
> before the next LibreSSL release

Not true.  The transition work on OpenSSH can start as soon as all
required interfaces are available in OpenBSD-current *and* the
OpenSSH developers have time to work on it and want to.

That said, it is likely that such a work would also be started
shortly after an OpenBSD release, to have maximum headroom before
the next OpenBSD release, in order to avoid shipping something that
is only half-finished or half-tested.

> * distributions that decided to phase out OpenSSL 1.0.2 in favor of
> OpenSSL 1.1 will have to support an OpenSSH patch that will grow
> smaller and smaller at each release.

Once again, no, they shouldn't.  They ought to build against OpenSSL-1.0
or LibreSSL until an OpenSSH release supporting 1.1 is available.
A 3000+ line vendor patch is always a terrible idea, and even more
so for an important piece of security software.

> BTW, do you know any other software that uses the LibreSSL API the
> same way OpenSSH is using it (i.e. LibreSSL is the primary target,
> OpenSSL compatibility is of lesser importance)?

Here is the list from the OpenBSD base system, only regarding
libcrypto.  Also checking the OpenBSD ports tree would be too much
work, but usually, there is much more stuff in the ports tree
than in the base system.

  program           portable version

  acme-client(8)    https://kristaps.bsd.lv/acme-client/
  bc(1)
  dc(1)
  ftp(1)
  keynote(1)
  nc(1)
  openssl(1)
  x99token(1)
  dhcpd(8)
  httpd(8)          https://bsd.plumbing/
  iked(8)           http://www.openiked.org/
  ikectl(8)         http://www.openiked.org/
  isakmpd(8)
  ldapctl(8)
  ldapd(8)
  login_token(8)
  npppd(8)
  ntpd(8)           http://www.openntpd.org/
  ocspcheck(8)
  radiusctl(8)
  radiusd(8)
  relayd(8)         https://bsd.plumbing/
  sasyncd(8)
  smtpd(8)          https://www.opensmtpd.org/
  smtpctl(8)
  snmpd(8)
  spamd(8)
  spamlogd(8)
  syslogd(8)
  tcpdump(8)
  tokeninit(8)
  ypldap(8)
  tls_init(3)

Yours,
  Ingo


More information about the openssh-unix-dev mailing list