name based virtual host és az ssl

Ezidáig a címben szereplő témára nem igazán volt lehetőség. Az volt a gond, hogy a http protokoll fölött ment az ssl kapcsolat létrehozása, az ssl kapcsolat létrehozásakor viszont a TLS handshake nem közvetítette hogy melyik virtualhosthoz szeretne csatlakozni majdan a http. Kb így zajlik rendesen:
K: Kapcsolódás
Sz: Nyilvános kulcs küldése (host1.hu)
K: Fogadás után a nyilvános kulcs segítségével elkezdi küldeni a titkosított http folyamot.
K: (titkosított adat, host1.hu PK) HTTP Kérés
Sz: (titkosított adat, host1.hu PK) HTTP válasz

Az okosok viszont kitalálták, mi lenne ha a TLS handshake során (mint az SMTP során a hello-val), elküldené azt is a kliens hogy kihez szeretne csatlakozni (host2.hu u.a. mint host1.hu):

K: Kapcsolódás (host2.hu -t küldi, a többi kötelező adat mellett).
Sz: Megkapott adatok alapján host2.hu nyilvános kulcsának küldése.
K: (titkosított adat, host2.hu PK) HTTP Kérés
Sz: (titkosított adat, host2.hu PK) HTTP válasz

Ennek a technikának a neve Server Name Indication (SNI). Mindehhez a TLS 1.1-t kell támogatnia a kliensnek. Nézzük milyen kliensek támogatottak (kapcsolódó wiki alapján):

  • Mozilla Firefox 2+
  • Opera 8.0+ (TLS 1.1-t be kell kapcsolni)
  • Internet Explorer 7+ (csak Vista!)
  • Google Chrome (Vista, XP nem)
  • Safari 3.2.1 Mac OS X 10.5.6

Szerver oldalon:

  • Apache 2.2.12+ vagy mod_gnutls mod_ssl helyett. (OpenSSL esetén 0.9.8f+, j-től default)
  • Utolsó lighttpd

Azok a kliensek akik nem támogatják továbbra is kapják az ssl_error_bad_cert_domain -t a többiek számára megoldódik az ilyen jellegű probléma.
Rossz hír az ubuntusok számára, hogy a Karmic ugyan az apache 2.2.12-t fogja szállítani, viszont OpenSSL-ből csak a 0.9.8f-et ami bizony a funkcionalitás backportja nélkül édes kevés…
Szóval megoldás már van csak meg kell várni míg elterjed!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.