Wie kann ich Nicht-SNI-Browser (ohne SNI-Unterstützung) simulieren?

Question

Ich richte Apache mit mehreren verschiedenen SSL-Zertifikaten für verschiedene Domänen ein, die sich auf demselben Server befinden (und somit dieselbe IP-Adresse teilen).

Mit Qualys SSL Test entdeckte ich, dass es Clients gibt (d. H. BingBot as of december 2013), die die SNI-Erweiterung nicht unterstützen.

Also denke ich darüber nach, eine spezielle Standard-Webanwendung zu erstellen, die die Anforderungen solcher Clients erfassen kann, aber wie kann ich diese Clients simulieren?

Ich bin auf Windows 8, keinen Zugriff auf Linux-Boxen, wenn das zählt.

Answer 1

Sie könnten Strawberry Perl installieren und dann das folgende Skript verwenden, um einen Client nicht unterstützt SNI zu simulieren:

use strict; 
use warnings; 
use LWP::UserAgent; 

my $ua = LWP::UserAgent->new(ssl_opts => { 
    # this disables SNI 
    SSL_hostname => '', 
    # These disable certificate verification, so that we get a connection even 
    # if the certificate does not match the requested host or is invalid. 
    # Do not use in production code !!! 
    SSL_verify_mode => 0, 
    verify_hostname => 0, 
}); 

# request some data 
my $res = $ua->get('https://example.com'); 

# show headers 
# pseudo header Client-SSL-Cert-Subject gives information about the 
# peers certificate 
print $res->headers_as_string; 

# show response including header 
# print $res->as_string; 

Durch die Einstellung SSL_hostname auf einen leeren String Sie SNI deaktivieren können, können Sie diese Zeile deaktivieren wieder SNI.

Answer 2

Sie können die am häufigsten verwendete SSL-Bibliothek OpenSSL verwenden. Windows-Binärdateien können heruntergeladen werden.

openssl s_client -connect domain.com:443 Befehl dient sehr gut zum Testen der SSL-Verbindung von Client-Seite. Es unterstützt standardmäßig nicht SNI. Sie können das Argument -servername domain.com anhängen, um SNI zu aktivieren.

Answer 3

Über spezielle Standard-Web-Anwendung ... Sie können nicht nur das tun.

Sie können das nicht tun, weil die begrenzten Clients nicht nur eine andere Seite öffnen, sondern sie vollständig ausfallen.

1. Betrachten Sie einen "Standard" -Vhost, den ein Nicht-SNI-Client gut öffnen wird.

2. Sie haben auch einen zusätzlichen vhost, der von einem SNI-unterstützenden Client geöffnet werden soll.

3. Offensichtlich müssen diese zwei verschiedene Hostnamen haben (sagen wir default.example.com und www.example.com), sonst würde Apache oder nginx nicht wissen, welche Seite zu welchem ​​verbindenden Client angezeigt werden soll. Jetzt

, wenn ein Nicht-SNI-Client versucht, https://www.example.com zu öffnen, er wird ein Zertifikat von default.example.com präsentiert, die ihm einen Zertifikatsfehler geben würden. Dies ist ein wichtiger Vorbehalt.

Eine Lösung für diesen Fehler besteht darin, ein SAN (Multi-Domain) -Zertifikat zu erstellen, das sowohl www.example.com als auch default.example.com enthält. Wenn dann ein Nicht-SNI-Client versucht, https://www.example.com zu öffnen, wird ihm ein gültiges Zertifikat angezeigt, aber selbst dann würde sein Host:-Header immer noch auf www.example.com zeigen, und seine Anforderung wird nicht an default.example.com, sondern an www.example.com weitergeleitet.

Wie Sie sehen, blockieren Sie entweder Nicht-SNI-Clients vollständig oder leiten sie an einen erwarteten vhost weiter. Es gibt keine sinnvolle Option für eine Standard-Webanwendung.

Answer 4

Ähnlich openssl s_client ist gnutls-cli

gnutls-cli --disable-sni www.google.com