Zahn - Unix-Netzwerkprogramminerung mit Threads, Sockets und SSL

318 6 Netzwerkprogrammierung mit SSL
SSL auf einem separaten Port
Die ersten SSL-fähigen Netzwerkdienste haben für die sichere Datenübertragung
einen separaten Port gewählt. Das bekannteste Beispiel ist sicher
das in RFC 2818 beschriebene HTTP Over TLS (HTTPS), das auf einem
dafür reservierten Port (vorgesehen ist Port 443) SSL-verschlüsselte HTTP-
Verbindungen entgegennimmt und im Webbrowser an den mit https:// zu
erkennen ist. SSL-fähige Webserver nehmen also gleichzeitig auf zwei verschiedenen
Ports Anfragen entgegen, sie hören zum einen auf Port 80 auf ungesicherte
Netzwerkverbindungen und warten zum anderen auf Port 443 auf das
Eintreffen neuer SSL-Verbindungen.
Die beschriebene Vorgehensweise wird auch zur Absicherung einer ganzen
Reihe anderer Anwendungsprotokolle eingesetzt, etwa bei POP3S (das Post
Office Protocol über SSL) oder SSMTP (das Simple Mail Transfer Protocol
über SSL). Für alle Anwendungsprotokolle, die auf diese Weise durch
SSL geschützt werden, gilt, daß bei diesem Verfahren lediglich eine unverschlüsselte
Netzwerkverbindung durch eine verschlüsselte Verbindung ersetzt
wird und daß das Anwendungsprotokoll davon unberührt bleibt. Server und
Client müssen also im Rahmen ihrer Kommunikation immer noch die selbe
Sprache sprechen und die gleichen Nachrichten austauschen.
Abgesehen von einem etwas verschwenderischen Umgang mit den verfügbaren
Ports funktioniert dieser Weg für einfache Netzwerkdienste ausgezeichnet.
Komplexere Server sind jedoch dazu in der Lage, sogenannte virtuelle Hosts
zu bilden und diese dann verschiedenen DNS-Namen zuzuordnen. Ein solcher
Server bietet seine Dienste also gleichzeitig für mehrere DNS-Namen an, was
für die Nutzer der Dienste so aussieht, als würden diese von jeweils einem
eigenen, dedizierten Server bereitgestellt. Dabei können zwei unterschiedliche
DNS-Namen durchaus auf dieselbe IP-Adresse verweisen. Damit der Server
nun auch in diesem Spezialfall weiß, als welcher der vielen virtuellen Hosts er
gerade eine Anfrage erhält, bettet der Client den gewünschten DNS-Namen in
seine Anfrage mit ein. Ohne diese Zusatzinformation wäre der Server machtlos,
denn er hört ja für alle virtuellen Hosts an der selben Socket-Adresse, d. h.
an der selben Kombination aus IP-Adresse und Port. Was für unverschlüsselte
Netzwerkverbindungen prima funktioniert, stößt mit SSL aber plötzlich auf
ein echtes Problem: Der Server muß bereits beim Aufbau der SSL-Verbindung
ein zum DNS-Namen passendes Zertifikat vorweisen. Nachdem er allerdings
erst im Laufe der Anfrage erfährt, an welchen virtuellen Host die Anfrage
tatsächlich gerichtet ist, ist er dummerweise genau dazu nicht in der Lage. 13
13 Unter den in RFC 3546 [BWNH + 03] vereinbarten TLS-Erweiterungen findet sich
auch eine Erweiterung, die dieses DNS-Namen-Problem für SSL-basierte Server
mit virtuellen Hosts löst.