Ist es möglich, ein SSL-Protokoll in Apache für einen einzelnen VirtualHost (Pudel) festzulegen?

13

Ich versuche, einen Patch für die Pudel-Sicherheitsanfälligkeit zu testen , bei der SSLv3 auf meinem Webserver deaktiviert wird. Um dies zunächst in einer Nicht-Produktionsumgebung zu testen, setze ich SSLProtocol auf einem VirtualHost für einen anderen Testserver. Meine Konfiguration sieht ungefähr so aus:

<VirtualHost *:443>
    SSLEngine On
    SSLProtocol All -SSLv2 -SSLv3
    ServerName test.mysite.com
    # bunch of other stuff omitted
</VirtualHost>

Aber auch nach dem Neustart von Apache wird meine Testseite immer noch als anfällig eingestuft. Wird das voraussichtlich funktionieren? Ich frage mich, ob ich es in der globalen SSL-Konfiguration einstellen muss oder ob es noch etwas Subtiles gibt, das bewirkt, dass die Einstellung nicht übernommen wird und / oder funktioniert.

— Cory
quelle

16

Sie können das SSL-Protokoll nur für den ersten VirtualHost in der Konfigurationsdatei festlegen. Alle nachfolgenden VirtualHost-Einträge übernehmen diese Einstellung vom ersten Eintrag und ignorieren ihre eigene Einstellung aufgrund eines OpenSSL-Fehlers unbemerkt .

Es gibt einen entsprechenden Fehlerbericht für mod_ssl , aber wie im Fehlerbericht beschrieben, muss das Problem in OpenSSL behoben werden (Zertifikat wird vererbt, aber nicht die Protokolle).

Die Cipher Suites müssen für jeden VirtualHost separat festgelegt werden, da Sie sonst die Standardliste mit vielen unsicheren Chiffren erhalten. Beachten Sie auch, dass ältere Clients, die keine Server Name Indication (SNI) unterstützen, immer den Standardhost verwenden (es sei denn, dies wird durch die Verwendung von blockiertSSLStrictSNIVHostCheck ). Dies kann zu Problemen beim Testen führen.

Kurz gesagt, Sie sollten in der Lage sein, benutzerdefinierte Cipher Suites und Zertifikate für jeden virtuellen Host anzugeben, aber bis der Fehler behoben ist, sollten Sie nicht mit einem korrekten Verhalten bei benutzerdefinierten Protokollen für jeden virtuellen Host rechnen.

Ich bin auf dieses Problem mit Apache 2.4 und Modssl mit OpenSSL 1.0.1k gestoßen und erwarte, dass Apache 2.2 denselben Problemen unterliegt.

Update (Oktober 2016): Der OpenSSL-Fehler wurde am 13. Oktober 2016 als behoben markiert. Er war jedoch Teil eines Massenabschlusses offener Probleme, und obwohl ein 'Teil-Fix' bereitgestellt wurde, wurde das Problem nie vollständig behoben.

Update (April 2018): Für den erneut eingereichten OpenSSL-Fehler ist jetzt ein Patch verfügbar (Stand 9. April 2018). Dieser Patch ändert das Verhalten von Apache-Instanzen, die mit mehreren virtuellen SNI-Hosts konfiguriert sind:

Lehnen Sie Verbindungen ab, die nicht mit vhost SSLProtocol übereinstimmen

Dies wurde mit 2.4.27 entwickelt und getestet und in Produktion mit dieser Version. Der Patch wurde für 2.4.33 modifiziert und leicht getestet.

Hiermit wird die Version der Verbindung mit dem SSL-Protokoll verglichen, das für den virtuellen Host konfiguriert ist, der anhand der SNI abgeglichen wird. Da die Verbindung anfänglich mit dem für den Standardhost für den Port konfigurierten SSL-Protokoll hergestellt wird, muss der Standardhost alle Protokolle enthalten, die von einem virtuellen Host unterstützt werden.

Dieser Patch fügt der Funktion init_vhost den zusätzlichen Rückgabestatus APR_EMISMATCH hinzu, sodass der bei OpenSSL registrierte Rückruf ssl_callback_ServerNameIndication die schwerwiegende Warnung SSL_AD_PROTOCOL_VERSION zurückgeben kann. Dies soll die gleiche Antwort für das ClientHello erzeugen wie die Angabe eines SSLProtocols, das die betreffende Version nicht enthält. Da der SNI-Rückruf während der Verarbeitung des ClientHello aufgerufen wird und bevor eine Antwort erzeugt wird, scheint er genau das zu tun.

Wenn Sie plötzlich Nachrichten im folgenden Format sehen:

Rejecting version [version] for servername [hostname]

Dann sollten Sie noch einmal SSLProtocolnach Ihrem Standardhost suchen.

— vallismortis
quelle

Die zusätzlichen Informationen, die von @anx in Bezug auf hinzugefügt wurden, werden SSLStrictSNIVHostChecksehr geschätzt. Aus der zitierten Dokumentation sollte jedoch auch hervorgehen, dass SNI-Clients, die nicht über diese Funktion informiert sind, nicht auf diesen bestimmten virtuellen Host zugreifen dürfen , wenn sie auf einem anderen virtuellen Host aktiviert sind .

— Vallismortis

5

Sie können für jeden Vhost unterschiedliche SSL-Protokolle verwenden, wenn diese eine andere IP abhören.

Beispiel mit einem bestimmten Host, der TLSv1 und alle anderen nur TLSv1.1 und TLSv1.2 zulässt - und einem, der nur TLSv1.2 zulässt:

<VirtualHost *:443>
  SSLEngine On
  SSLProtocol All -SSLv2 -SSLv3 -TLSv1
  ServerName test.mysite.com
  # bunch of other stuff omitted
</VirtualHost>

<VirtualHost 10.0.0.2:443>
  SSLEngine On
  SSLProtocol All -SSLv2 -SSLv3
  ServerName test2.mysite.com
</VirtualHost>

<VirtualHost 10.0.0.3:443>
  SSLEngine On
  SSLProtocol TLSv1.2
  ServerName test2.mysite.com
</VirtualHost>

— BitLegacy01
quelle

Wenn Sie es nur zu Testzwecken benötigen, können Sie auch einen anderen Port anstelle einer anderen IP verwenden, z. B. einen allgemeinen alternativen HTTPS-Port 8443.

— Esa Jokinen,

0

Wenn Sie die Server Name Indication (SNI) mit Ihrem vhost verwenden, können Sie in der Tat nicht mehrere SSL-Versionen definieren.

Wenn Sie jedoch einen dedizierten Server verwenden, können Sie Ihrem Server möglicherweise eine andere IP-Adresse hinzufügen. Auf diese Weise können Sie eine andere SSL-Version pro IP verwenden. Sie müssen lediglich Ihre vhost-Einstellungen wie erwartet ändern. IP: 443.

— tryp
quelle

-2

Oder Sie können verwenden:

SSLProtocol TLSv1 TLSv1.1 TLSv1.2

Ich wurde auf vielen Servern getestet und funktioniert für mich! Sie können Ihre Website auf dieser Website testen

— Rodrigo Moreno
quelle

4

Diese sslProtocol Linie nur sieht , wie es funktioniert , weil Apache darüber nicht beschweren. In der Realität wird nur das SSL-Protokoll im ersten VirtualHost-Eintrag verwendet.

— Vallismortis