Apache: MITM saldırılarını önlemek için SSL güven zincirini doğrulamak istiyor musunuz?


11

SSL ortadaki adam saldırılarının, özellikle şirket ortamlarında düşündüğümden çok daha yaygın olduğunu fark ettim. Şeffaf bir SSL proxy sunucusu bulunan birkaç işletmeyi duydum ve gördüm. Tüm istemciler bu proxy sertifikasına güvenecek şekilde yapılandırılmıştır. Bu temel olarak işverenin teorik olarak SSL şifreli trafiği bile tarayıcıda herhangi bir uyarı yapmadan yakalayabileceği anlamına gelir. Yukarıda belirtildiği gibi, müşteriler sertifika güvenilir olarak geliyor. Bu yalnızca kullanılan sertifikayı manuel olarak doğrulayarak açıklanabilir.

Bana göre, işveren, çalışanın SSL trafiğini gözetlemek için üstün konumunu kullanıyor gibi görünüyor. Benim için bu, tüm SSL kavramını güvenilmez kılıyor. Mitmproxy kullanarak benzer bir kurulumu kendim başarılı bir şekilde test ettim ve müşteri ile elektronik bankacılık sunucum arasındaki iletişimi okuyabildim. Bu kimseye açıklanmaması gereken bir bilgidir.

Bu yüzden sorum oldukça basit: Sunucu tarafında güven zincirini nasıl doğrulayabilirim? İstemcinin sunucumun sertifikasını ve yalnızca bir güven zincirini kullandığından emin olmak istiyorum. Acaba bunun Apache'nin SSL yapılandırmasıyla gerçekleştirilip gerçekleştirilemeyeceğini? Bu, birçok uygulamaya kolayca uygulanabileceğinden uygun olacaktır. Bu mümkün değilse, PHP bunu yapmak için bir yol biliyor mu? Veya başka bir öneriniz var mı?


1
İşveren çalışan trafiğini görürse sorun değil. İşverenin kaynaklarını (pc, ağ bağlantıları vb.) Kullanıyorsunuz, bunlar sizin değil. Ve eğer emplyer'ın bankacılık hesabınıza aktardığınız verileri görebileceğinden endişe ediyorsanız - işte değil evde yapın. Kurumsal güvenlik politikasını ihlal etme girişimleri, size karşı bir mahkemeye konu olabilir.
Crypt32

2
Birçok Avrupalı ​​şirkette ofis ekipmanlarının özel kullanımı iş sözleşmesinde düzenlenmiştir. Çalıştığım şirkette özel olarak sörf yapabilirim, bu bir sorun değil. Porno, dosya paylaşımı vb. İstisnalar vardır. Aynı zamanda şirketlerin çalışanlarına casusluk yapmasına izin vermeyen yasalar da vardır. Bu nedenle, benim ve diğerleri için - işverenlerin çalışan trafiğine müdahale etmesi uygun değildir, çünkü birçok şirkette özel sörf tolere edilirken bu açıkça yasaktır.
Aileron79

2
ABD Hükümeti'nin sahip olduğu iş istasyonlarının çoğu (her deneyimime göre) her girişte şu iki bildirimi içerir: "Bu IS'yi kullanan veya üzerinde depolanan veriler özel değildir, rutin izleme, müdahale ve aramaya tabidir ve ifşa edilebilir veya kullanılabilir Bu ISG, kişisel yararınız veya gizliliğiniz için değil, USG çıkarlarını korumak için güvenlik önlemlerini (örn. kimlik doğrulama ve erişim kontrolleri) içerir. Bu sistemlerin kullanımı genellikle bunu öngören imzalanmış bir anlaşma ile kapsanır. Kilit ayrıntı, sistemin sahibinin kendilerini kendinize karşı korumasıdır.
Randall

Bu, ABD ve Avrupa arasındaki birçok farktan biri. @Randall'ın yukarıda belirtilen şartları çoğu Avrupa ülkesinde yasa dışıdır.
Aileron79

Alıntıladığım terimler eksik, diğer terimler açıkça izlenmeyen faaliyetleri listeler. Avrupalı ​​işverenlerin bu tür önkoşulları bilgisayarlarını kullanma koşulu haline getiremediklerine dair herhangi bir referans bulamıyorum (Avrupa'da faaliyet gösteren bir şirket için çalışıyorum, bu tür izleme süreçlerini ayarlıyorum, ancak iş yapmayan bir bölüm için çalışıyorum Avrupa), ancak bu tür terimlerin açık ve şeffaf oldukları sürece yasa dışı olmadığını öneren referanslar bulabilir.
Randall

Yanıtlar:


9

Bu sorunun MITM konusunun birçok soruda tartışıldığı security.stackexchange.com için daha uygun olacağını düşünüyorum . Her neyse:

Sunucu sertifikasının doğrulanması yalnızca istemcide yapılır ve istemcide sertifikayı doğrulama noktası, istemcinin doğru sunucuyla konuştuğundan ve güvenemediğinden emin olması gerektiği için bir şekilde sunucuya taşınamaz. (güvenilmeyen) sunucuyu istemci için bu kararı verir.

SSL müdahalesi durumunda, sunucu açısından TLS istemcisi SSL yakalama güvenlik duvarı / AV'dir. Bu nedenle, sunucu tarafındaki sorun, beklenen istemciyle (tarayıcı) konuşup konuşmadığını (güvenlik duvarı / AV) tespit etmektir. Bunu yapmanın en güvenli yolu istemcinin kimliğini doğrulamak için istemci sertifikalarını kullanmaktır - ve aslında istemci kimlik doğrulaması kullanılırsa SSL müdahalesi çalışmaz, yani MITM beklenen istemci sertifikasını sağlayamadığından TLS el sıkışması başarısız olur.

Yalnızca istemci sertifikaları nadiren kullanılır. Ayrıca, başarısız bir TLS anlaşması, istemcinin sunucuya SSL müdahalesi olmadan iletişim kurabileceği anlamına gelmez, ancak istemci sunucuyla hiç iletişim kuramaz. Alternatif bir yol, TLS el sıkışmasının parmak izine dayalı olarak TLS istemcisinin türünü tespit etmek için bazı sezgisel tarama kullanmak, yani şifrelerin türü ve sırası, belirli uzantıların kullanılması ... Bir SSL önleme proxy'si teoride orijinali taklit edebilirken Merhaba çoğu mükemmel değil. Ayrıca bkz Algılama man-in-the-middle HTTPS sunucu tarafında veya bölüm III TLS Uygulama Sezgiseller içinde HTTPS Kesişme Güvenlik Impact .


14

Bana göre, işveren, çalışanın SSL trafiğini gözetlemek için üstün konumunu kullanıyor gibi görünüyor. Benim için bu, tüm SSL kavramını güvenilmez kılıyor

Sorun SSL kavramında veya teknik uygulamada değil, başka birinin bağlantının bir uç noktası, yani iş istasyonunuz üzerinde tam kontrole sahip olması.
Gerçek güvenlik riskinin kökü budur ...

Güvenlik açısından, normal şartlarda bir MITM'nin başarılı olmasını engelleyen güven zincirini bozan iş istasyonunuz tehlikeye girer.

Sunucu tarafında güven zincirini nasıl doğrulayabilirim?

Yapamazsın. Bu müşteri tarafında yapılır.

Kullanım durumunuza bağlı olarak, gerçek SSL sertifikalarınızı veya kullandığınız CA'ları içeren bir listeyle (karma) istemciye ek bir başlık gönderdiğiniz RFC 7469 HTTP Genel Anahtar Sabitleme'dir .


4
HPKP, sertifika açıkça eklenmiş bir CA tarafından imzalanırsa tarayıcılar tarafından yok sayılacağı için yardımcı olmaz. Bu özellikle güvenilir bir tarafın SSL müdahalesine izin vermek için yapılır, yani şirket güvenlik duvarı veya yerel bir masaüstü AV (çoğu SSL müdahalesinde bulunur).
Steffen Ullrich

2
Orada kesinlikle haklısınız: RFC'den §2.6: "Yerel ilkeye göre bazı Ana Bilgisayarlar için Pin Doğrulamasının devre dışı bırakılmasına izin verilmesi kabul edilebilir. Örneğin, UA, onaylanmış sertifika zinciri şu adreste sona eren Sabitlenmiş Ana Bilgisayarlar için Pin Doğrulamasını devre dışı bırakabilir UA'ya (veya temel alınan platforma) yerleşik bir güven bağlantısı yerine kullanıcı tanımlı bir güven bağlantısı. "
HBruijn

3

Yanlış yol bu. Sunucu güven zincirini kontrol etmez. Müşteri. Bu nedenle şirketin bu şekilde kullanılmasının nedeni, şirketin env güvenliğini sağlamak ve çalışanın çalışma zamanında ne yaptığını kontrol etmektir.


Evet, bunun sadece sunucu tarafında önlenemeyeceğinin farkındayım. Ancak, bazı istemci tarafı JS de kandırılmış olabilir. BTW, Çoğu Avrupa ülkesinde çalışanlara casusluk yapmak yasa dışıdır. Bir web sitesi operatörü olarak müşterilerimin kandırılmasını önlemek istiyorum, bu yüzden güven zincirini güvenli bir şekilde doğrulayabilmemin herhangi bir yolu olup olmadığını merak ediyorum.
Aileron79

Belki izin verilmez. Ancak çoğu şirket, yalnızca şirket ağını güvenceye almak isteyen çalışanlara casusluk yapmaz ve çoğu web filtresi veya tarayıcı, bunu kontrol etmek için SSL bağlantısını kesmelidir. Bu orta saldırıda yasal bir adam
beli3ver

Ne demek istediğini anlıyorum. Ancak, bu soru HTTPS bağlantısının uçtan uca şifrelenmesini nasıl sağlayabileceğim hakkındadır. Yukarıda tarif ettiğim kurulum, kurumsal ortamlarda çok yaygındır, ancak kıskanç çocuklar tarafından kız arkadaşlarına casusluk yapmak veya kiracı trafiğini kesen ev sahipleri tarafından aynı tür bir saldırı kullanılabilir. Bu kişilerin hala bir sertifika yüklemek için kandırılmaları gerekiyor, ancak bu kolay kısım. Ancak, bu yasadışı - ve hala bir HTTPS bağlantı gerçekten şifreli e2e sağlamak için herhangi bir yolu olup olmadığını merak ediyorum.
Aileron79

3
Bu mümkün değil. Kök sertifika istemcide değiştirildiğinde, denetlemenin bir yolu yoktur. Sunucu kontrolü yapmaz, istemci kontrolü yapar.
beli3ver

3

Siz (bir çeşit) OLABİLİRSİNİZ , ama asıl soru, YOK ETMEK .

Ancak, apache.conf'daki bir bayrağı değiştirmek kadar basit değildir.

Ayrıca, "saldırgan" olarak (örn. İşveren) onlar olabilir, istemci bilgisayarı kontrol eden hep senin girişimleri folyo yeterli çaba harcamaya meyilli olup olmadığını çok büyük balık olmadıkça, iyi tarafından (bunlar büyük olasılıkla değildir böylece kullanıcılarınızın güvenli olmadıkça size bağlanamayacağı hedefinize ulaşırsınız))

  • Eğer olabilir javascript TLS reimplement ve istemci bağlandığında sertifikası web sitenizin belgesi varsa sizin kontrol yok.

  • Eğer şanslıysanız , kullanıcı istemci tarafı Javascript'in kullanılan uzak sertifika hakkında bilgi alabileceği tarayıcı kullanıyor olabilir (ve böylece sunucunuzun sertifikasının sabit kodlanmış değeriyle kolayca doğrulayabilir).

  • özel şifrelemenizi çalıştırmak için JavaScript kullanabilirsiniz . Dolayısıyla, şirketin kötü TLS MiTM başarılı olsa bile, yine de verilerinize erişmesine izin vermez. Tabii ki, yeterince ilgiliyse (ve müşteriyi kontrol ettikleri için), anında güvenli javascript'inizi, transit olan tüm bilgileri kaydeden (veya değiştiren) kendi ile değiştirebilirler.

Ayrıca, TLS MiTM proxy'leri kullanan işletmeler de genellikle istemci bilgisayarı tamamen kontrol ettiğinden, kullanıcının gördüğü her şeyin videosunu kaydetmek ve kullanıcının yazdığı tüm tuş vuruşlarını (ve fare hareketlerini) kaydetmek için ekran ve keylogger'ı kolayca kurabilirler. Gördüğünüz gibi saldırgan zaman, IS müşteri, onu kandırmak için hiçbir kesinlikle güvenli bir yolu yoktur. Gerçekten ne kadar rahatsız edecekleri sorusu ... Ve yukarıdaki çözümlerden bazıları sizin için yeterince iyi olabilir.


" TLS'yi javascript'te yeniden uygulayabilirsiniz " Nasıl? Nerede?
curiousguy

@curiousguy metin qouted bir bağlantı olduğunu - üzerine tıklayın ve sizi başka bir soru ve cevap ve son olarak digitalbazaar / Forge projesine
götürecektir

Peki, ne zaman kullanılabilir? Hangi amaçla?
curiousguy

@curiousguy, özellikle bu Serverfault sorusunda sorulan amaçlar için, birçok şey arasında. İstemcide çalışan kendi JS TLS'niz olduğunda, bu istemci JS, istemcinin hangi TLS sunucusuna bağlandığını tam olarak bilir (ve genel anahtardır). Daha sonra bu ortak anahtarı yetkili sunucu ortak anahtarıyla (JS'nizde sabit kodlanmış) ve bunların aynı olup olmadığını bileceksiniz. Aynı değilse, bağlantınız MiTM tarafından kaçırıldı.
Matija Nalis
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.