SNI ve HTTP tarafından sağlanan alanlar arasında çatışma


22

Geçenlerde bir WordPress web sitesini küçük bir mağazada barındırma sağlayıcısından kendi çalışan Ubuntu Server 12.04.2 LTS ve Apache 2.2.22 sunucusuna taşıdım. Mağaza için SSL istiyorum. Sunucu için yeni bir IP üzerine birkaç tane basit vhost kurdum, biri belirli IP'nin 80 numaralı portuna, diğeri ise 443 numaralı portun bağlanması. Her ikisi de ServerName www.example.comve ServerAlias example.comvhost config içinde. Benim var SSLStrictSNIVHostCheck off.

Site çok yavaş çalışıyor, ancak çalışıyor. Hata günlüklerimde aşağıdakileri alıyorum.

[Error] Hostname example.com provided via SNI and hostname www.example.com provided via HTTP are different

Yavaşlığın yukarıdaki mesajla ilişkili olduğunu bekliyorum. Neden göründüğü ve bunun hakkında ne yapabileceğim hakkında bir fikriniz var mı?

Yanıtlar:


24

Erişim günlüğüne bak (hata günlüğüne değil). Hatanın tarih ve saatiyle, rahatsız edici isteği tanımlayabilmeli ve kullanıcı aracısını bulabilmelisiniz. Benim durumumda, bir bot oldu:

"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.2)"

Sunucum HTTP 400: Kötü İstek ile cevap veriyor.

Yanılmıyorsam, TLS görüşmelerinde, istemci ana bilgisayar adını iki kez gönderir: bir kez SNI (Sunucu Adı Gösterimi) 'de SSL bağlantısı kurulmadan ve bir kez gerçek HTTP isteğinden SONRA. Sunucu adları uyuşmazsa, bu durum bozuk bir istemciye işaret eder ve sunucunuzun nasıl yapılandırıldığı ile ilgisi olmamalıdır.

Belki bir gün botlarını tamir edeceklerdir, bu arada muhtemelen görmezden gelebilirsiniz. İstekler çok yüksek bir oranda gelmediği sürece bunun ev sahibi üzerinde yavaşlamaya neden olabileceğinden şüpheleniyorum.


11

Belki bu hata, sunucunuzdaki güvenlik açıklarını test etmek için bazı istemciler tarafından kasten ortaya çıkarılmıştır. Bir isteğin, researchscan367.eecs.umich.edututtuğum bir sunucudaki hatayı tetiklediğini tespit ettim. Bu durumda, hatanın ortaya çıkması iyi bir şeydir.

Ne tür saldırıların mümkün olduğunu merak ediyordum ve bu soruyu Security Stack Exchange'de sordum: Apache2'nin hata kodu AH02032 tarafından ne tür bir saldırı engelleniyor?


1

İlk bakışta müşteri sorununa benziyor ... Bu soruna hangi tarayıcı neden geliyor?

Mesaj, istemcinin ssl bağlantısı sırasında gönderdiği ana makine adının, SSL katmanı oluştuğunda istemcinin HTTPS isteğinde gönderdiği ile aynı olmadığını gösterir.


Buna neyin sebep olduğunu bilmiyorum. Hata, müşteri bilgilerini bildirmiyor. Sadece bunu düzenli olarak gördüğümü biliyorum. ServerAlias'ın bunu mutlu etmek için yeterli olduğunu umuyordum, çünkü teoride sunucu www.domain.com ve domain.com'un eşdeğer olduğunu biliyor.
flickerfly

@ flickerfly Evet, bu bir alıcı istemci ve tanımlayamadığınız sürece yapabileceğiniz pek bir şey yok.
Michael Hampton

2
Tamam, sadece 443 numaralı bağlantı noktası için NameBasedVirtualHost yönergesini kaldırarak SNI'yi devre dışı bıraktım. Sanırım bu noktada buna ihtiyacım yok. Bence çalışması gerekiyordu.
flickerfly

1

Benim durumumda alt çizgi ile yeni bir sanal ev sahibi oluşturmak problemdi. Joker bir SSL sertifikam var.

İşe yaramadı:

<VirtualHost *:443>
        SSLEngine on
        ServerName sub_domain.example.com
        Redirect / https://www.example.com/restofmyredirectlink
</VirtualHost>

Apache başarıyla yeniden başlatılsa da, HTTP 400 hataları alıyorum. Hata günlüğünde:

[Wed Sep 05 11:28:00.349960 2018] [ssl:error] [pid 19906:tid 140392626808576] AH02031: Hostname sub_domain.example.com provided via SNI, but no hostname provided in HTTP request

Ancak alt çizgiyi kaldırmak işe yaradı:

<VirtualHost *:443>
        SSLEngine on
        ServerName subdomain.example.com
        Redirect / https://www.example.com/restofmyredirectlink
</VirtualHost>

1
ServerFault'a Hoşgeldiniz. Ana bilgisayar adlarına alt çizgi koymak RFC'lere aykırıdır ve çeşitli şekillerde bozulur. stackoverflow.com/questions/2180465/…
civcivler

1
Kesinlikle! Bu yüzden şimdi burada da referans olarak var.
MS,

0

Etki alanı adını yerel (dahili) bir IP adresine ataıp ayırmadığınızı görmek için / etc / hosts dosyanızı kontrol edin. / Etc / hosts service nscd restart komutunu değiştirdikten sonra ad servis önbellek arka planını yeniden başlatmayı unutmayın

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.