Giriş
Sanal Hosting birden fazla web sitesine hizmet verme uygulamasıdır. aynı sunucu. Günümüzde norm olmasına rağmen, HTTP'nin ilk günlerinde (1.1'den önceki sürümler) bu mümkün değildi.
Başlangıçta, bir sunucu yalnızca aynı makinede birden fazla web sitesini barındırabilir (yani, aynı IP adresi altında), her web sitesine ayrı bir bağlantı noktası atanması şartıyla. Bu ideal bir çözüm değildi çünkü tarayıcılar varsayılan olarak bağlantı noktasına 80 Kullanıcı farklı bir tane belirtmedikçe HTTP için. Sonuç olarak, çoğu web sitesi sahibi, kullanıcıların doğru bağlantı noktası numarasını hatırlamama ve farklı bir web sitesinde sona erme riskinden kaçınmak için özel bir sunucu seçti.
Bununla birlikte, daha fazla kullanıcı Web'e katıldıkça ve daha fazla ağ cihazı çevrimiçi görünmeye başladıkça, mevcut IP adreslerinin sayısı endişe verici bir oranda azalmaya başladı. Bu beklenen tükenme olarak bilinen IPv4 adres aralığı tükenmesi, endüstriyi çeşitli karşı önlemler tasarlamaya ve uygulamaya yönlendirmiştir. IPv6 (IPv4'ün halefi), destekleyebilir ihtiyacımız olandan daha fazla adres. Ne yazık ki, IPv6 geçerli bir çözüm olmasına rağmen, benimsenmesi oldukça yavaştı. Göre Google'ın IPv6 istatistikleri, bu yazının yazıldığı sırada İnternet cihazlarının yaklaşık% 25'i IPv6 üzerinden konuşlandırılmıştır.
Sanal barındırma aynı zamanda tükenme sorununa erken bir çözüm olarak uygulandı. Host HTTP 1.1'deki başlık. HTTP 1.1 üzerinden iletişim kuran tarayıcılar artık bir sunucunun bağlantı noktasına bağlanabildi 80 ve alan adını ekleyin (örn. www.ssl.com) ziyaret etmek istedikleri web sitesinin Host başlık. Bir sunucunun aynı bağlantı noktasında kaç site barındırdığına bakılmaksızın, bu bilgileri doğru web sitesini belirlemek ve içeriğini iade etmek için kullanabilir.
HTTPS ve Sanal Barındırma
Bununla birlikte, ağ güvenlik açıkları ve web kullanıcılarına yönelik saldırılar hakkında yayınlanan çok sayıda rapor, endüstriyi güvenli olmayan HTTP'den daha güvenli alternatif HTTPS'ye geçmeye başlayın. Geniş kabulü HTTPS genel kullanıcı güvenliğini artırdı. Bununla birlikte, ek geliştirmeleri, web iletişimlerinin genel karmaşıklığını da artırmıştır.
Prensip olarak, HTTPS, tarayıcılar ve sunucular arasındaki HTTPS iletişiminin şifrelenmesi dışında HTTP'ye oldukça benzerdir. Kısaca, HTTPS, sunucuların tarayıcılara genel olarak güvenilen bir tarafından verilen geçerli bir SSL sertifikası sağlamasını gerektirir. Sertifika yetkilisi (CA), örneğin SSL.com. Bir tarayıcı daha sonra sertifikada bulunan genel anahtarı kullanarak sunucu ile şifrelenmiş bir iletişim kanalı kurmak. Ayrıca, tarayıcının, kullanıcının ziyaret etmek istediği alan adıyla eşleşip eşleşmediğini kontrol eden belirli bir alan adı için bir sertifika verilir. Böylece, sunucu kaç web sitesini barındırırsa barındırsın, tarayıcılar talep ettikleri web sitesi için geçerli bir SSL sertifikası bulmayı beklerler.
Dikkatli okuyucu sorunu zaten hissediyor olabilir: tarayıcı, şifreli kanalı kurmak ve şifreli kanalı göndermek için doğru web sitesinin sertifikasını gerektirir. Host başlık, sunucuya ihtiyaç duyarken Host doğru sitenin sertifikasını bulmak için başlık. Bu klasik bir tavuk ve yumurta problemidir.
HTTP için tasarlandığı şekliyle sanal barındırmanın HTTPS için çalışmadığı açıktır, çünkü güvenlik kontrolleri tarayıcıların Host bilgileri sunucuya aktarır. Bununla birlikte, IPv4 tükenme sorunu hala çözülmemişken ve endüstrinin bulut teknolojilerini (yük dengeleme ve çoklu yük devretme arka uç sunucuları gerektiren) giderek artan şekilde benimsemesiyle, sanal barındırma hala bir zorunluluktur.
Çoklu Alan Sertifikaları Ne Olacak?
Bu soruna önerilen bir çözüm, çok alanlı veya SAN sertifikaları. Tek bir SAN sertifikası yüzlerce farklı alan adını güvence altına alabilir ve tarayıcılar, ziyaret etmeye çalıştıkları alan adını SAN sertifikasının alan listesinde bulurlarsa şikayet etmezler. Şifrelenmiş kanal yapılandırıldıktan sonra, tarayıcı Host başlığını sunucuya ekleyin ve diğer durumlarda olduğu gibi devam edin. Bu, halihazırda mevcut ve mevcut bir teknolojiyi kullanan harika bir fikirdir, ancak SAN sertifikalarının güvenliğini sağlayan aynı mekanizmalar, birkaç potansiyel olarak istenmeyen yan etkilere de yol açmıştır:
SAN sertifikaları, aynı varlığın (kişi, şirket veya kuruluş) sahip olduğu birden çok etki alanını güvence altına almak için iyi bir araçtır, ancak paylaşımlı barındırmada kullanımı bir şekilde pratik değildir; Sertifikaya yeni bir etki alanı eklenmeye veya sertifikadan kaldırılmaya hazır olduğunda, en son etki alanı listesini içeren yeni bir sertifika CA tarafından verilmeli ve tüm etki alanlarında yeniden dağıtılmalıdır.
Ayrıca, SAN sertifikaları yalnızca şu şekilde verilebilir: Organizasyon Onaylı (OV) veya Genişletilmiş Doğrulanmış (EV) if herşey etki alanları aynı kuruluşa aittir. Bu doğrulama seviyeleri, CA tarafından doğrulanan olası sertifika sahibinin bilgilerinin miktarı ve türleri sertifikayı vermeden önce. Doğrulama seviyesi ne kadar yüksek olursa, kullanıcıların web sitesine o kadar çok güven duyduğu ve kullanıcı güveninin marka tanınırlığını ve dönüşüm oranlarını etkileyebileceği gösterilmiştir.
Son olarak, paylaşılan web barındırma ortamlarında bir şirketin bir sunucuyu diğer işletmeler veya kuruluşlarla (rakipleriyle bile) paylaşması oldukça yaygındır. SAN sertifikalarındaki etki alanları halka açık olarak listelendiğinden, işletme sahipleri aynı sertifikayı üçüncü taraf şirketlerle paylaşmak konusunda isteksiz olabilir.
SAN sertifikaları, sayısız uygulamaya sahip güçlü ve çok yönlü araçlar olmasına rağmen, bu sorunlar, IETF'i - İnternet standartlarının yönetim organı - sanal olarak barındırılan HTTPS web sitelerinin belirli sorunlarına daha iyi uyan yaklaşımlar aramaya motive etti.
Kurtarmaya Sunucu Adı Göstergesi
Çözüm şu şekilde uygulandı: Sunucu Adı Göstergesi (SNI) uzantısı TLS protokol (HTTPS'nin şifreleme ile ilgilenen kısmı).
SNI, tarayıcıların bağlantı sırasında bağlanmak istedikleri alan adını belirlemelerine olanak sağlar. TLS tokalaşma (sunucuyla ilk sertifika görüşmesi). Sonuç olarak, web siteleri, paylaşılan bir IP adresi ve bağlantı noktasında barındırılırken kendi SSL sertifikalarını kullanabilir, çünkü HTTPS sunucuları, bağlantıyı kurmak için gereken uygun sertifika zincirini tanımlamak için SNI bilgilerini kullanabilir.
Daha sonra, şifreli iletişim kanalı yapılandırıldığında, tarayıcı web sitesinin alan adını Host başlığı açın ve normalde olduğu gibi devam edin. Esasen SNI, HTTP'ler ile aynı işlevi yerine getirir. Host şifreli bağlantının oluşturulması sırasında başlık.
Bu basit numara sonunda sunucuların aynı bağlantı noktasında birden fazla HTTPS web sitesini barındırmasına izin verdi. Ancak, çoğu İnternet teknolojisinde olduğu gibi, SNI'nin bazı sınırlamaları vardır.
SNI Desteği Kaygıları
SNI, 1999'da ilk tasarlandığından beri oldukça olgun olsa da, onu desteklemeyen birkaç eski tarayıcı (Windows XP'de IE) ve işletim sistemleri (Android sürümleri <= 2.3) vardır. SNI'yi destekleyen tarayıcıların ve işletim sistemlerinin kapsamlı bir listesi için lütfen şu adrese bakın: bu masa.
SNI'yi desteklemeyen tarayıcıların pazar payları (ve buna bağlı olarak bunun meydana gelişleri) modern tarayıcılarla karşılaştırıldığında küçük olsa da, bir tarayıcı SNI'yı tanımazsa varsayılan SSL sertifikasına geri dönecek ve potansiyel olarak bir yaygın ad uyuşmazlığı hatası.
Google gibi birçok şirket, onu destekleyen istemciler için SNI uygular ve desteklemeyen ender durumlarda SAN sertifikalarına geri döner. Doğal olarak, giderek daha fazla kullanıcı ve işletme sahibi sistemlerini modern teknolojilere yükselttikçe bu sorunun azalması bekleniyor.
SNI Gizlilik Kaygıları
Şu anki kararlı sürümü TLS (sürüm 1.2), el sıkışmasının ilk bölümünü ve SNI bilgilerini şifrelenmemiş olarak iletir. Sonuç olarak, bir ağ saldırganı, web iletişimlerinin kendileri tamamen şifrelenmiş olmasına rağmen, bir kullanıcının web geçmişini keşfedebilir.
Amazon veya Google gibi çeşitli bulut hizmeti sağlayıcıları, şu adla bilinen (kirli) bir geçici çözüme izin verdi alan önü. Etki alanı ön görünümü, bulut sağlayıcısının ana makine adını kullanarak SNI bilgilerini gizlediği için web geçmişinin açığa çıkmasını engelleyebilir. TLS negotiation ve hedef site HTTP başlığındadır. Ancak, Google ve Amazon kamuoyuna açıkladıkları için bu yöntem artık geçerli değildir. etki alanı ön görünümü için devre dışı bırakılmış destek 2018 Nisan ayı itibariyle hizmetlerinde.
Neyse ki, daha sistematik bir çözüm önerilmiştir. deneysel taslak detaylandırma Şifreli SNI (ESNI) en yeni için uzantı TLS 1.3 sürümü ESNI, SNI bilgilerini şifreler ve böylece tüm gizlilik endişelerini azaltır. Ne yazık ki, TLS 1.3, endüstri tarafından henüz yaygın olarak benimsenmemiş olsa da TLS 1.3, yavaş yavaş fiili ağ güvenlik protokolü haline geliyor. ESNI'nin durumu ve HTTPS'nin gizliliği hakkında bizden gelecek makalelere göz atın ve TLS.
Sonuç
Özetle, SNI ile tek bir sunucuda milyonlarca HTTPS web sitesini barındırabilirsiniz. Ancak, bireysel durumunuza bağlı olarak, bir SAN sertifikası sizin için daha iyi sonuç verebilir. SNI ile ilgili gizlilik endişeleri hala var, ancak ESNI ile potansiyel bir çözüm de var. Her durumda, bu iki yöntemden birini veya birkaçını kullanarak, minimum çabayla tüm web siteleriniz için sanal barındırmayı kolayca uygulayabilirsiniz.
SNI hakkında daha fazla sorunuz varsa veya SAN'lar ile SNI arasında nasıl seçim yapacağınızı bilmiyorsanız, müşterilerimizin kendi PKI ihtiyacı var. Bize bir e-posta bırakın support@ssl.com ve bir uzman size yardımcı olacaktır.
