Server Name In­di­ca­ti­on (SNI): Was steckt hinter dem Standard?

Si­cher­heit spielt im Internet eine sehr große Rolle. Deshalb versuchen Standards, Zer­ti­fi­ka­te und Pro­to­kol­le sowohl die Nutzer als auch Server vor schäd­li­chen Angriffen zu schützen. Eines dieser Pro­to­kol­le nennt sich Transport Layer Security (TLS). Da dieses aber Probleme mit sich bringt, wurde mit der Server Name In­di­ca­ti­on (SNI) eine Er­wei­te­rung ge­schaf­fen.

Bevor man verstehen kann, warum SNI ent­wi­ckelt wurde, muss man nach­voll­zie­hen, wie TLS funk­tio­niert. Bei dem Nach­fol­ger vom Secure Sockets Layer (SSL) findet ein so­ge­nann­ter TLS-Handshake statt. Dabei tauschen Client und Server – in der Praxis also meist der Web­brow­ser und die Website – In­for­ma­tio­nen aus, noch bevor die ei­gent­li­che Da­ten­über­tra­gung beginnt. Bei diesem vir­tu­el­len Hand­schlag iden­ti­fi­ziert sich der Server gegenüber dem Client und sendet auch das ent­spre­chen­de Si­cher­heits­zer­ti­fi­kat. Erst wenn der Client dieses ve­ri­fi­ziert hat, nehmen beide Kom­mu­ni­ka­ti­ons­part­ner eine Ver­bin­dung auf und tauschen Daten aus. Fällt die Ve­ri­fi­ka­ti­on negativ aus, findet keine weitere Da­ten­über­tra­gung statt.

Was passiert aber, wenn mehrere Websites über eine IP-Adresse laufen, wie beim Virtual Hosting? Da sich IPv6 noch immer nicht durch­ge­setzt hat, arbeiten wir in einem sehr be­grenz­ten IP-Adress­rah­men, und nicht jede Domain kann eine eigene IP-Adresse für sich be­an­spru­chen. An wen richtet der Client sein „Hello“ (der erste Schritt eines TLS-Hand­shakes) dann? Die Wahr­schein­lich­keit, dass die falsche Website reagiert, nicht das korrekte Zer­ti­fi­kat – mit dem richtigen Hostnamen – sendet und die Ver­bin­dung damit nicht zustande kommt, ist groß. Deshalb ist es notwendig, dass der Client dem Server mitteilt, zu welcher Domain (Host) er eine Ver­bin­dung aufnehmen möchte. Dafür hat man die Server Name In­di­ca­ti­on ein­ge­führt.

Wenn bei einer un­ge­si­cher­ten Ver­bin­dung der Fall auftritt, dass mehrere Websites über eine IP-Adresse laufen, hat man das Problem prin­zi­pi­ell nicht. In

HTTP

ist es vor­ge­se­hen, dass der Hostname beim Anfordern einer Website in einem Header angegeben ist. Bei TLS muss aber der Handshake geschehen, bevor der Web­brow­ser diese Angabe überhaupt versenden kann. Die Server Name In­di­ca­ti­on sorgt dafür, dass der Hostname bereits vor dem Zer­ti­fi­kats­aus­tausch zwischen Server und Client über­mit­telt wird.

SNI ist eine Er­wei­te­rung zu TLS. Das Ver­schlüs­se­lungs­pro­to­koll ist Teil des TCP/IP-Pro­to­koll­sta­pels. Als solcher erweitert TLS das Trans­mis­si­on Control Protocol (TCP) um eine Ver­schlüs­se­lung. Durch die zu­sätz­li­che Schicht wird außerdem aus HTTP HTTPS. Hat man TLS durch die Server Name In­di­ca­ti­on erweitert, stellt das Si­cher­heits­pro­to­koll beim Handshake ein weiteres Feld zur Verfügung: Unter dem Feld Cli­ent­Hel­lo­Ex­ten­si­on findet man das optionale Feld Ser­ver­Na­me. In dieses Feld trägt der Client (und das übernimmt der Web­brow­ser au­to­ma­tisch) den Namen des Hosts ein, den er an­spre­chen möchte. So ist gesichert, dass der richtige Host antwortet.

Als ge­wöhn­li­cher In­ter­net­nut­zer sollte man von den Vorgängen rund um SNI gar nichts mit­be­kom­men. In den meisten Fällen müssen Nutzer dafür nichts in­stal­lie­ren oder ein­stel­len. Es reicht voll­kom­men, wenn Sie ein aktuelles Be­triebs­sys­tem und einen modernen Browser verwenden. Firefox, Chrome, Edge, Opera und Safari un­ter­stüt­zen die Er­wei­te­rung stan­dard­mä­ßig. Einzig Nutzern, die noch Windows XP (oder sogar ältere Windows-Versionen) nutzen und darin den Internet Explorer verwenden, steht Server Name In­di­ca­ti­on nicht zur Verfügung. Sollte man sich immer noch auf dem in­zwi­schen nicht mehr mit Updates un­ter­stüt­zen Be­triebs­sys­tem bewegen, hat man jedoch die Mög­lich­keit, einen anderen Browser ein­zu­set­zen, der SNI un­ter­stützt. Auch die meisten mobilen Browser verwenden SNI.

Server Name In­di­ca­ti­on hat nicht nur Vorteile. Zum einen wird SNI nicht von allen Web­brow­sern un­ter­stützt – dies betrifft al­ler­dings nur eine zu­ge­ge­be­ner­ma­ßen geringe Zahl von Nutzern. Dass es sich bei SNI aber nicht um ein perfektes Modell handelt, sondern nur um eine Über­gangs­lö­sung, erkennt man daran, dass In­for­ma­tio­nen un­ver­schlüs­selt über­mit­telt werden. Es ist zwar nur der Hostname, aber auch diese In­for­ma­ti­on sollte bei einer gründ­li­chen Ver­schlüs­se­lung nicht von Dritten ab­ge­grif­fen werden können. Mehr Si­cher­heit ist also gegeben, wenn man kein SNI einsetzen muss und jede Website ihre eigene IP-Adresse erhält.

Da sich dies aufgrund des knappen IP-Adress­rah­mens (zumindest bis IPv6 global ein­ge­führt wird) nicht ändern lässt, muss man andere Mög­lich­kei­ten finden. Eine dieser Mög­lich­kei­ten stellt SNI dar. Eine andere wären Subject-Al­ter­na­ti­ve-Name-Zer­ti­fi­ka­te (SAN): Bei diesen Zer­ti­fi­ka­ten hat man die Mög­lich­keit, mehrere Domains bzw. Hostnamen ein­zu­tra­gen. Das würde im Um­kehr­schluss bedeuten, dass es für den Server egal ist, welche Domain der Client tat­säch­lich an­spre­chen möchte, denn das Zer­ti­fi­kat ist für alle Domains auf dem Server gültig. Der Nachteil dieser Zer­ti­fi­ka­te ist aber, dass sie ver­gleichs­wei­se kost­spie­lig sind. Deshalb sind viele Website-Betreiber ver­ständ­li­cher­wei­se nicht bereit, solche Zer­ti­fi­ka­te zu im­ple­men­tie­ren. Statt also gar keine Ver­schlüs­se­lung ein­zu­set­zen, stellt SNI eine gute Zwi­schen­lö­sung dar.