1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
/* This file is a sample configuration for apt https method. Configuration
parameters found in this example file are expected to be used in main
apt.conf file, just like other configuration parameters for different
methods (ftp, file, ...).
This example file starts with a common setup that voluntarily exhibits
all available configurations knobs with simple comments. Extended
comments on the behavior of the option is provided at the end for
better readibility. As a matter of fact, a common configuration file
will certainly contain far less elements and benefit of default values
for many parameters.
Because some configuration parameters for apt https method in following
examples apply to specific (fictional) repositories, the associated
sources.list file is provided here:
...
deb https://secure.dom1.tld/debian unstable main contrib non-free
deb-src https://secure.dom1.tld/debian unstable main contrib non-free
deb https://secure.dom2.tld/debian unstable main contrib non-free
deb-src https://secure.dom2.tld/debian unstable main contrib non-free
...
Some notes on the servers:
- secure.dom1.tld is freely accessible using https (no client
authentication is required).
- secure.dom1.tld certificate is part of a multi level PKI, and we
want to specifically check the issuer of its certificate. We do
not have the constraint for secure.dom2.tld
- secure.dom2.tld requires client authentication by certificate
to access its content.
- The certificate presented by both server have (as expected) a CN that
matches their respective DNS names.
- It somtimes happens that we had other more generic https available
repository to our list. We want the checks to be performed against
a common list of anchors (like the one provided by ca-certificates
package for instance)
The sample configuration below basically covers those simpe needs.
*/
// Verify peer certificate and also matching between certificate name
// and server name as provided in sources.list (default values)
Acquire::https::Verify-Peer "true";
Acquire::https::Verify-Host "true";
// Except otherwise specified, use that list of anchors
Acquire::https::CaInfo "/etc/ssl/certs/ca-certificates.pem";
// Use a specific anchor and associated CRL. Enforce issuer of
// server certificate using its cert.
Acquire::https::secure.dom1.tld::CaInfo "/etc/apt/certs/ca-dom1-crt.pem";
// Like previous for anchor and CRL, but also provide our
// certificate and keys for client authentication.
Acquire::https::secure.dom2.tld::CaInfo "/etc/apt/certs/ca-dom2-crt.pem";
Acquire::https::secure.dom2.tld::SslCert "/etc/apt/certs/my-crt.pem";
Acquire::https::secure.dom2.tld::SslKey "/etc/apt/certs/my-key.pem";
// No need to downgrade, TLS will be proposed by default. Uncomment
// to have SSLv3 proposed.
// Acquire::https::mirror.ipv6.ssi.corp::SslForceVersion "SSLv3";
// No need for more debug if every is fine (default). Uncomment
// me to get additional information.
// Debug::Acquire::https "true";
/*
Options with extended comments:
Acquire::https[::repo.domain.tld]::CaInfo "/path/to/ca/certs.pem";
A string providing the path of a file containing the list of trusted
CA certificates used to verify the server certificate. The pointed
file is made of the concatenation of the CA certificates (in
PEM format) creating the chain used for the verification of the path
from the root (self signed one). If the remote server provides the
whole chain during the exchange, the file need only contain the root
certificate. Otherwise, the whole chain is required.
If you need to support multiple authorities, the only way is to
concatenate everything.
If None is provided, the default CA bundle used by GnuTLS (apt https
method is linked against libcurl-gnutls) is used. At the time of
writing, /etc/ssl/certs/ca-certificates.crt.
If no specific hostname is provided, the file is used by default
for all https targets. If a specific mirror is provided, it is
used for the https entries in the sources.list file that use that
repository (with the same name).
Acquire::https[::repo.domain.tld]::Verify-Peer "true";
When authenticating the server, if the certificate verification fails
for some reason (expired, revoked, man in the middle, lack of anchor,
...), the connection fails. This is obviously what you want in all
cases and what the default value (true) of this option provides.
If you know EXACTLY what you are doing, setting this option to "false"
allow you to skip peer certificate verification and make the exchange
succeed. Again, this option is for debugging or testing purpose only.
It removes ALL the security provided by the use of SSL.TLS to secure
the HTTP exchanges.
Acquire::https[::repo.domain.tld]::Verify-Host "true";
The certificate provided by the server during the TLS/SSL exchange
provides the identity of the server which should match the DNS name
used to access it. By default, as requested by RFC 2818, the name
of the mirror is checked against the identity found in the
certificate. This default behavior is safe and should not be
changed. If you know that the server you are using has a DNS name
which does not match the identity in its certificate, you can
[report that issue to its administrator or] set the option to
"false", which will prevent the comparison to be done.
The options can be set globally or on a per-mirror basis. If set
globally, the DNS name used is the one found in the sources.list
file in the https URI.
Acquire::https[::repo.domain.tld]::SslCert "/path/to/client/cert.pem";
Acquire::https[::repo.domain.tld]::SslKey "/path/to/client/key.pem";
These two options provides support for client authentication using
certificates. They respectively accept the X.509 client certificate
in PEM format and the associated client key in PEM format (non
encrypted form).
The options can be set globally (which rarely makes sense) or on a
per-mirror basis.
Acquire::https[::repo.domain.tld]::SslForceVersion "TLSv1";
This option can be use to select the version which will be proposed
to the server. "SSLv3" and "TLSv1" are supported. SSLv2, which is
considered insecure anyway is not supported (by gnutls, which is
used by libcurl against which apt https method is linked).
When the option is set to "SSLv3" to have apt propose SSLv3 (and
associated sets of ciphersuites) instead of TLSv1 (the default)
when performing the exchange. This prevents the server to select
TLSv1 and use associated cipheruites. You should probably not use
this option except if you know exactly what you are doing.
Note that the default setting does not guarantee that the server
will not select SSLv3 (for ciphersuites and SSL/TLS version as
selectio is always done by the server, in the end). It only means
that apt will not advertise TLS support.
Debug::Acquire::https "true";
This option can be used to show debug information. Because it is
quite verbose, it is mainly useful to debug problems in case of
failure to connect to a server for some reason. The default value
is "false".
*/
|
