apt-get sources should support TLS SNI (server name)

[TJ Pusateri]

There needs to be an option in apt source.list entries to specify the server name to be used by TLS for the Server Name Indication (SNI).

The openSSL equivalent is '-servername'.

Currently, when accessing sources over https when multiple names are used on the same IP address, there is no way to specify which server name should be used and so the default name is always used.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: apt 1.0.1ubuntu2.11
ProcVersionSignature: Ubuntu 4.2.0-30.35~14.04.1-generic 4.2.8-ckt3
Uname: Linux 4.2.0-30-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.19
Architecture: amd64
Date: Mon Feb 29 17:25:22 2016
InstallationDate: Installed on 2016-02-26 (3 days ago)
InstallationMedia: Xubuntu 14.04.4 LTS "Trusty Tahr" - Release amd64 (20160217.1)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: apt
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[TJ Pusateri (pusateri)]

Something like this would be useful:

sudo add-apt-repository 'deb [servername=foo.bar.com] http://foo.bar.com/ trusty main'

[Joy Bhattacherjee (joy-bhattacherjee)]

nodesource repository is broken because of this,

Steps to reproduce:

```
curl --silent https://deb.nodesource.com/gpgkey/nodesource.gpg.key | sudo apt-key add -
add-apt-repository 'deb https://deb.nodesource.com/node_5.x main trusty main'
sudo apt-get update
```

[Joy Bhattacherjee (joy-bhattacherjee)]

issue on nodesource repo: https://github.com/nodesource/distributions/issues/388

[David Kalnischkies (donkult)]

That would be horrible… If you contact a server foo.example.org it should respond with the cert for it, not with a cert for bar.example.com. That is what SNI is all about after all (as your client connects to an IP and SNI is telling the server which hostname it wanted to connect to, so the server can respond with the right cert).

I somehow doubt a highlevel interface like libcurl even exposes such a detail. The bugreport you reference is speculating about all sorts of things, so one of them might be it. I would personally consider a bug in libcurl-gnutls most likely (note that this is not always the library behind curl. It seems to be in newer releases, older releases use libcurl (the openssl variant)).

As an additional datapoint: On Debian stretch the command "/usr/lib/apt/apt-helper download-file 'https://deb.nodesource.com/gpgkey/nodesource.gpg.key' 'nodesource.gpg'" works just fine, so in newer versions that seems resolved.

Anyway, this report is a mixture between a feature request we will not be implement and a bug we don't have – as such marked as invalid in apt as you are better of finding the real culprit and report a new bug against that.

P.S.: apt doesn't need https for integrity. Given the sorry state of CAs (compare e.g. StartSSL/WoSign) that wouldn't really be secure… There are other reasons you might want https even in case of apt, but blank statements aren't making anyone more secure – they just make them feel secure.

[TJ Pusateri (pusateri)]

I think you may have misunderstood the request. I have a server that supports multiple domains and each have their own TLS certificates. Using the openssl client, I can connect to each of the unique hostnames. They all map back to the same IP address.

But if I host a repo over TLS on this server, this fails because it receives the primary server name TLS certificate instead of the hostname specified in the source list. This is exactly the scenario SNI was invented for.

[TJ Pusateri (pusateri)]

Also, in this case, TLS isn't being used for integrity, it's being used for privacy. Everything over the internet should be encrypted at this point.

[David Kalnischkies (donkult)]

So, how is this option named in firefox and how do you set it? ……… exactly. You don't have it as an option as servername != hostname is something you only need for experiments which is the main purpose of s_client. Firefox doesn't need that option as it is using SNI (in reality it uses a library which does, but details). apt doesn't need the option as it is using libcurl-gnutls which is using SNI (see the apt-helper command above as proof). That this isn't working in your case on your system is a bug "somewhere", possibly libcurl-gnutls or the things it uses like libgnutls, but not a reason to request a servername option in apt which given that you want to set it with servername == hostname would be a NOP anyhow…

P.S.: Fire up wireshark and realize that HTTPS itself fails your blank "everything should be encrypted" statement. The irony is that SNI is actually one of those unencrypted but highly informational pieces. The rest is a bit of traffic analyze away as you have perfect knowledge of the entirely static data sent over the encrypted wire, so from the transfer size alone you can already make reasonable guesses about what you do and with a bit more work you can be sure. Better than nothing of course and one of the reasons I subsumed under "you might want" but its still mostly a feeling of security/privacy you get here as apt just isn't your typical dynamically created website with cookies and passwords and stuff resulting in unique data streams where HTTPS makes a lot more sense. IF you and repository owners were really into privacy, you would be using TOR and repositories on onion services (for the record, apt supports it via apt-transport-tor and some repositories are available as onion service).

[TJ Pusateri (pusateri)]

These are good points. The servername argument should not be necessary. I will dig deeper and figure out the real problem. Thanks.