Vysvetleni nastaveni APACHE

Jan Houstek jan.houstek na mff.cuni.cz
Čtvrtek Únor 17 21:01:44 CET 2005


On Thu, 17 Feb 2005, Milan Keršláger wrote:

> > > Normalni WWW server muze mit na 1 IP adrese vice virtualu s
> > > rozdilnymi daty. SSL server musi byt na kazde IP jen 1 (protoze
> > > nelze pred zahajenim sifrovani rict, ktery vlastne chcete a podle
> > > toho vybrat klice).
> >
> > Neni problem pro vice jmen pouzit jeden certifikat, viz archiv listu.
>
> Jenze ciste reseni to neni.

Aha, to by nebyl Milan, aby nemel posledni slovo :)

Udelejme si tedy mensi exkuzri do RFC, a pak se uvidi, co je a neni ciste
reseni.

* RFC 3546 - Transport Layer Security (TLS) Extensions, kapitola 1

"Specifically, the extensions described in this document are designed to:

- Allow TLS clients to provide to the TLS server the name of the server
  they are contacting.  This functionality is desirable to facilitate
  secure connections to servers that host multiple 'virtual' servers at a
  single underlying network address."

Na urovni rozsireneho klientskeho TLS HELO je zde umozneno specifikovat
server name a umoznit serveru vybrat odpovidajici certifikat. Namatkou
jsem prozkoumal nejbeznejsi TLS implementace a nemely s timto standardem
problem. Neni to ale jedina moznost, viz napr.:

* RFC 2595 - Using TLS with IMAP, POP3 and ACAP, sekce 2.4

"During the TLS negotiation, the client MUST check its understanding of
the server hostname against the server's identity as presented in the
server Certificate message, in order to prevent man-in-the-middle attacks.
Matching is performed according to these rules:
[...]
- If the certificate contains multiple names (e.g. more than one dNSName
  field), then a match with any one of the fields is considered
  acceptable."

Tedy jinymi slovy, klient akceptuje jeden certifikat vydany pro vice jmen
(at uz pomoci dNSName, subjectAltName nebo CN.n). Zajimame-li se konkretne
o HTTP, neunikne nasi pozornosti

* RFC 2818 - HTTP Over TLS, sekce 3.1

"If a subjectAltName extension of type dNSName is present, that MUST be
used as the identity. Otherwise, the (most specific) Common Name field in
the Subject field of the certificate MUST be used. Although the use of the
Common Name is existing practice, it is deprecated and Certification
Authorities are encouraged to use the dNSName instead."

Je to sice zatim jen proposed standard (ale to treba RFC 2821 taky), ale
naprosto jednoznacne rika, ze klient MUSI podporovat dNSName +
subjectAltName a bezne pouzivane uvadeni jmena serveru pomoci CN je
zastarale.

Opet potvrzuji, ze zadna me znama implementace SSL/TLS nema v aktualni
verzi jiz nejaky ten patek s timto standardem problem.

Neciste je v kazdem pripade pouzivani Common Name pro svazani certifikatu
s DNS jmenem serveru, ale co je necisteho na vyse uvedenych standardech,
to bys mel asi trochu vysvetlit ...

-- Honza Houstek


Další informace o konferenci Linux