TLS / SSL (HTTPS) şifrelemesi kullanılırken tüm URL'ler şifreli mi? TLS / SSL (HTTPS) kullanırken tüm URL verilerinin gizlenmesini istediğim için bilmek istiyorum.

TLS / SSL size toplam URL şifrelemesi sağlıyorsa, gizli bilgileri URL'lerden gizleme konusunda endişelenmem gerekmez.

Evet, SSL bağlantısı TCP katmanı ile HTTP katmanı arasındadır. İstemci ve sunucu önce güvenli bir şifrelenmiş TCP bağlantısı (SSL / TLS protokolü aracılığıyla) kurar ve ardından istemci bu şifrelenmiş TCP bağlantısı üzerinden HTTP isteğini (GET, POST, DELETE ...) gönderir.

Kimse bir tel yakalama sağlamadığından, bir tane.
Sunucu Adı (URL'nin etki alanı kısmı) ClientHellopakette düz metin olarak sunulur .

Aşağıda bir tarayıcı isteği gösterilmektedir:
https://i.stack.imgur.com/path/?some=parameters&go=here

TLS sürüm alanları hakkında daha fazla bilgi için bu cevaba bakınız (3 tane var - sürümler değil, her biri sürüm numarası içeren alanlar!)

Gönderen https://www.ietf.org/rfc/rfc3546.txt :

3.1. Sunucu Adı Göstergesi

[TLS] bir istemciye bir sunucuya iletişim kurduğu sunucunun adını söylemesi için bir mekanizma sağlamaz. İstemcilerin, temel bir tek ağ adresinde birden çok 'sanal' sunucu barındıran sunuculara güvenli bağlantıları kolaylaştırmak için bu bilgileri vermeleri istenebilir.

Sunucu adını sağlamak için, istemciler (genişletilmiş) istemci merhaba "sunucu_adı" türünde bir uzantı içerebilir.

Kısacası:

• FQDN (URL'nin alanı kısmı) MAYIS iletilebilir açık olarak iç ClientHelloSNI uzantısı kullanılırsa paket

• İstek URL'si bir HTTP işi (OSI Katman 7) olduğundan, URL'nin ( /path/?some=parameters&go=here) geri kalanında herhangi bir işletme ClientHellobulunmaz, bu nedenle asla TLS anlaşmasında görünmez (Katman 4 veya 5). Bu bir de daha sonra gelecek GET /path/?some=parameters&go=here HTTP/1.1, HTTP isteği SONRA güvenli TLS kanalı oluşturulur.

YÖNETİCİ ÖZETİ

Alan adı açık bir şekilde iletilebilir (TLS anlaşmasında SNI uzantısı kullanılıyorsa), ancak URL (yol ve parametreler) her zaman şifrelenir.

MART 2019 GÜNCELLEME

Bunu getirdiğin için teşekkürler carlin.scott .

SNI uzantısındaki taşıma kapasitesi artık bu taslak RFC teklifi yoluyla şifrelenebilir . Bu özellik sadece TLS 1.3'te mevcuttur (bir seçenek olarak ve bunu uygulamak her iki tarafa da bağlıdır) ve TLS 1.2 ve altı ile geriye dönük uyumluluk yoktur.

CloudFlare bunu yapıyor ve burada iç kısımlar hakkında daha fazla bilgi edinebilirsiniz - Tavuk yumurtanın önüne gelmesi gerekiyorsa, tavuğu nereye koyarsınız?

Pratikte bu, FQDN'yi düz metin olarak iletmek yerine (Wireshark yakalama şovları gibi) artık şifreli olduğu anlamına gelir.

NOT: Bu, ters DNS araması yine de hedeflenen hedef ana bilgisayarı gösterebileceğinden, gizlilik yönünü güvenlikten daha fazla ele alır.

Gibi diğer cevaplar zaten işaret vardır, https "URL'ler" gerçekten de şifrelenir. Bununla birlikte, etki alanı adını çözerken DNS isteğiniz / yanıtınız muhtemelen değildir ve elbette bir tarayıcı kullanıyorsanız URL'leriniz de kaydedilebilir.

URL dahil tüm istek ve yanıt şifrelenir.

Bir HTTP Proxy kullandığınızda, hedef sunucunun adresini (etki alanını) bildiğini, ancak bu sunucuda istenen yolu bilmediğini unutmayın (örn. İstek ve yanıt her zaman şifrelenir).

Önceki cevaplara katılıyorum:

Açık olmak gerekirse:

TLS ile URL'nin ilk kısmı ( https://www.example.com/ ) bağlantıyı kurdukça görünmeye devam eder. İkinci kısım (/ herearemygetparameters / 1/2/3/4) TLS tarafından korunmaktadır.

Ancak, GET isteğine parametre koymamanız için bir takım nedenler vardır.

İlk olarak, başkaları tarafından daha önce de belirtildiği gibi: - tarayıcı adres çubuğundan sızıntı - geçmişte sızıntı

Buna ek olarak http yönlendiricisi aracılığıyla URL sızıntısı da vardır: kullanıcı TLS'de A sitesini görür, ardından B sitesine giden bir bağlantıyı tıklatır. Her iki site de TLS'de ise B sitesine yönelik istek, A sitesindeki URL'yi isteğin yönlendirme parametresi. Ve B sitesindeki yönetici bunu B sunucusunun günlük dosyalarından alabilir.)

Marc Novakowski'nin yararlı yanıtına ek olarak - URL, sunucudaki günlüklerde saklanır (örn. / Etc / httpd / logs / ssl_access_log), bu nedenle sunucunun bilgileri daha uzun süre korumasını istemiyorsanız terimiyle URL'ye koymayın.

Evet ve hayır.

Sunucu adresi bölümü, bağlantıyı ayarlamak için kullanıldığından şifrelenmez.

Bu, gelecekte şifreli SNI ve DNS ile değişebilir, ancak 2018'den itibaren her iki teknoloji de yaygın olarak kullanılmamaktadır.

Yol, sorgu dizesi vb. Şifrelenir.

GET istekleri için kullanıcı URL'yi konum çubuğundan kesip yapıştırabilecektir ve muhtemelen ekrana bakan herkes tarafından görülebilecek gizli bilgileri koymak istemeyeceksiniz.

Trafiği izleyen bir üçüncü taraf, trafiğinizi inceleyerek ve başka bir kullanıcının siteyi ziyaret ederken sahip olduğu trafikle karşılaştırarak ziyaret ettiğiniz sayfayı belirleyebilir. Örneğin, bir sitede yalnızca biri diğerinden çok daha büyük olan 2 sayfa varsa, veri aktarımının boyutunun karşılaştırılması hangi sayfayı ziyaret ettiğinizi gösterir. Bunun üçüncü taraftan gizlenmesinin yolları vardır, ancak bunlar normal sunucu veya tarayıcı davranışı değildir. Örneğin SciRate'in bu makalesine bakınız, https://scirate.com/arxiv/1403.0297 .

Genel olarak diğer cevaplar doğrudur, ancak bu makale ziyaret edilen sayfaların (yani URL) oldukça etkili bir şekilde belirlenebileceğini göstermektedir.

Tam URL'nin gizliliğine her zaman güvenemezsiniz. Örneğin, bazen kurumsal ağlarda olduğu gibi, şirket PC'niz gibi sağlanan cihazlar ekstra bir "güvenilir" kök sertifika ile yapılandırılır, böylece tarayıcınız https trafiğinin proxy (ortadaki adam) denetimine sessizce güvenebilir . Bu, tam URL'nin incelemeye açık olduğu anlamına gelir. Bu genellikle bir günlüğe kaydedilir.

Ayrıca, şifreleriniz de açığa çıkmış ve büyük olasılıkla günlüğe kaydedilmiştir ve bu bir defalık şifreleri kullanmanın veya şifrelerinizi sık sık değiştirmenin başka bir nedenidir .

Son olarak, başka türlü şifrelenmezse istek ve yanıt içeriği de görünür.

Kontrol kurulumunun bir örneği Checkpoint tarafından burada açıklanmaktadır . Birlikte verilen PC'leri kullanan eski bir "internet kafe" de bu şekilde kurulabilir.

Yinelenen bir sorudaki cevabımla bağlantı kuruluyor . URL yalnızca tarayıcı geçmişinde mevcut değildir, sunucu tarafı da günlüğe kaydeder, ayrıca üçüncü taraf içeriği kullanırsanız URL'yi kontrolünüz dışındaki kaynaklara gösteren HTTP Yönlendiricisi başlığı olarak da gönderilir.

Şimdi 2019 ve TLS v1.3 piyasaya sürüldü. Cloudflare'ye göre, SNI, TLS v1.3 sayesinde şifrelenebilir. Bu yüzden kendime harika dedim! bulutflare.com'un TCP paketlerinde nasıl göründüğüne bakalım. Bu yüzden, tarayıcı sniper olarak Google Chrome'u kullanarak tarayıcı ve wireshark'ı kullanan bulut alevleme sunucusunun yanıtından bir "istemci merhaba" el sıkışma paketi yakaladım. İstemci Merhaba paketinde sunucu adını hala düz metin olarak okuyabilirim.

Bu nedenle, anonim bir bağlantı olmadığı için okuyabileceğiniz şeylere dikkat edin. İstemci ve sunucu arasındaki bir ara katman yazılımı, bir istemci tarafından istenen her etki alanını günlüğe kaydedebilir.

SNI'nin şifrelenmesi, TLSv1.3 ile birlikte çalışmak için ek uygulamalar gerektiriyor gibi görünüyor

Aşağıdaki makalede TLSv1.3'ün bir parçası olarak Cloudflare tarafından sağlanan SNI'nin şifrelenmesi açıklanmaktadır. Ancak, cloudflare.com adresindeki tüm HTTP URL'leri, TLS v1.3 altında TCP paketinde düz metin halindedir

[ https://blog.cloudflare.com/encrypted-sni/ Karışık [3 ]

Evet ve hayır.

Gerçek URL şifrelenmiştir, yani birisi ziyaret ettiğiniz bir web sitesindeki web sayfasını tam olarak anlayamaz. Ancak, TLS üstbilgisi şifrelenmemiş eriştiğiniz sunucunun ana bilgisayar adını (örn. Www.quora.com) içerir. DNS de neredeyse hiç şifrelenmez ve eriştiğiniz ana bilgisayar adını da sızdırır. Bu DNS sorgusu varsayılan olarak neredeyse her zaman ISS'nizin sunucularına karşıdır, bu nedenle DNS isteklerinizi diğer DNS sunucularına koklayarak veya kendi URL'lerinizi kaydederek eriştiğiniz her web sitesinin ana bilgisayar adını kolayca görebilirler.

Bununla birlikte, endişeniz birisinin hangi web sitesine eriştiğinizi öğrenip öğrenemeyeceği ise bu yeterli değildir. HTTPS, OSI Katman 4'te çalışır ve bu düzeydeki tüm verileri şifreler, ancak daha düşük düzeyler, onu taşıyan ağlara bırakılır. Birisi yine de OSI katman 3'teki trafiğin yolunu ve hedefini izleyebilir. Bu, trafiğinizi koklayan birinin IP adresini ve uzantıya eriştiğiniz web sitesinin alan adını bulabileceği anlamına gelir.

Daha da kötüsü, ilk kez (ve daha sonraki bazı zamanlarda, DNS önbelleğinizin nasıl / ne zaman temizlendiğine bağlı olarak) DNS sunucunuz HTTPS hedef URL'nizin IP adresini istemek için şifrelenmemiş bir DNS sorgusu gönderirsiniz (yine, DNS sunucunuzun yolu boyunca trafiğinize erişimi olan herkes bu sorguyu koklayabilir.

Yüksek bir gizlilik standardı arıyorsanız, HTTPS'yi güvenilir bir şifreli VPN ve / veya şifreli proxy hizmeti ile desteklemeniz gerekir. DNS sorgularınızı korumak için DNSSEC'yi de inceleyebilirsiniz. Bu hizmet güvenilir olmalıdır, çünkü trafiğinizin kaynaklarının ve hedeflerinin yukarıdaki izlemesini kolayca gerçekleştirebilirler.

Zaten burada bazı iyi cevaplar olduğunu düşündüm, çoğu tarayıcı navigasyonuna odaklanıyor. Bunu 2018'de yazıyorum ve muhtemelen biri mobil uygulamaların güvenliği hakkında bilgi edinmek istiyor.

Mobil uygulamalar için uygulamanın her iki ucunu (sunucu ve uygulama) kontrol ederseniz, HTTPS kullandığınız sürece güvende olursunuz . iOS veya Android sertifikayı doğrulayacak ve olası MiM saldırılarını azaltacaktır (tüm bunlarda tek zayıf nokta bu olacaktır). Hassas verileri, aktarım sırasında şifreleneceği HTTPS bağlantıları aracılığıyla gönderebilirsiniz . Sadece uygulamanız ve sunucu https yoluyla gönderilen parametreleri bilir.

Buradaki tek "belki", istemci veya sunucuya, https'ye sarılmadan önce verileri görebilen kötü amaçlı yazılım bulaşmışsa olabilir. Ancak birisine bu tür bir yazılım bulaşmışsa, onu taşımak için ne kullanırsanız kullanın, verilere erişimi olacaktır.

Buna ek olarak, bir ReSTful API oluşturuyorsanız, istemci bir tarayıcı olmayabilir ve bağlantıları tıklayan kişileriniz olmayabilir.

Bu durumda, bir taşıyıcı simgesi almak için oAuth2 girişini tavsiye ederim. Bu durumda, tek hassas veriler ilk kimlik bilgileri olacaktır ... muhtemelen yine de bir post isteğinde bulunmalıdır

Zaten çok iyi cevaplarınız olsa da, bu web sitesindeki açıklamayı gerçekten seviyorum: https://https.cio.gov/faq/#what-information-does-https-protect

Kısacası: HTTPS kullanmak gizler:

• HTTP yöntemi
• sorgu parametreleri
• POST gövdesi (varsa)
• İstek başlıkları (çerezler dahil)
• Durum kodu