HTTPS üzerinden Kimlik Doğrulama Uygulamamı Yavaşlatır mı?


11

Bir web uygulaması ve RESTful web hizmeti oluşturuyorum.

Web hizmetine olan isteklerin kimliğini doğrulamanın en iyi yolu hakkında çeşitli makaleler okudum.

Benim için en iyi seçenek HTTP temel kimlik doğrulamasını kullanmak gibi görünüyor. Okuduğum hemen hemen her makale, kimlik doğrulamanın SSL veya eşdeğeri üzerinden şifrelenmesi gerektiğini söylüyor.

Bunun ne içerdiğinden tam olarak emin değilim. Bu, tüm web servisimin güvenli bir sunucuda olması gerektiği anlamına mı geliyor? Bu yavaşlıyor mu?


Https üzerinden yüklenen verilerin bir düşünce, erişilebilirliği. Bunun nasıl / nasıl etki edeceğinden% 100 emin değilim.

takip ettiğimden emin değilim. Önbelleğe almanın mümkün olmadığını mı söylüyorsun?
Gaz_Edge

SSL / https ile web sunucusu arasında REST ile istenmeyen etkileşimler olabilir - cxf.547215.n5.nabble.com/… - Güvenli bir ortamda REST'e çok fazla girmedim , bu yüzden bu bir benim için sorun. Bir apache yöneticisi olarak benim günümden daha fazla düşünce ve ipuçları.

Teşekkürler. Güvenli bir ortamda REST kullanmadığınızı söylüyorsunuz. Bu, kimlik doğrulamayı kullanmadığınız anlamına mı geliyor? Yoksa http basic için farklı bir şekilde mi yapıyorsunuz?
Gaz_Edge

Onun ya hiçbir kimlik doğrulama, temel, ya da ip tabanlı ... ve tamamen bir intranet (hiçbir şey harici bakan).

Yanıtlar:


11

Her şeyden önce, SSL (HTTPS) ve HTTP kimlik doğrulamasının nasıl çalıştığını anlamaya çalışın.

Her zamanki HTTP kimlik doğrulama yöntemleri (Özet, Temel ve HTTP'nin üzerine uygulayabileceğiniz formlar + çerez tabanlı kimlik doğrulama düzeni) kimlik doğrulaması bilgilerini az çok düz metin olarak gönderdikleri için kendiliğinden güvensizdir. Verilerin POST alanlarında veya üstbilgilerinde olup olmadığı ve base64 kodlamasının uygulanıp uygulanmadığı bu açıdan hiç önemli değildir, parola ağ trafiğine erişimi olan herkes tarafından açıkça görülebilir. Bu, güvenilmeyen bir kanal üzerinden HTTP kimlik doğrulamasının değersiz olduğu anlamına gelir: bir saldırganın parolanızı okuması için gereken tek şey biraz ağ koklamasıdır.

SSL , doğal olarak güvensiz bir kanal üzerinden güvenli bir iletişim kanalı uygular. Bu, kabaca şu şekilde çalışır:

  1. Sunucu imzalı bir sertifika gönderir
  2. İstemci sertifikayı bilinen iyi imzalama anahtarları listesine göre doğrular; Sertifika imzaları zincirlenebilir, böylece her düğüm "beni imzalayan imza iyi ise ben de öyleyim" der, ancak nihayetinde, zincirin istemcide önceden yapılandırılmış birkaç güvenilir otoriteden birine çözümlemesi gerekir.
  3. İstemci, paylaşılan bir sırrı göndermek için sunucunun genel şifreleme anahtarını kullanır
  4. Sunucu paylaşılan anahtarın şifresini özel anahtar kullanarak şifresini çözer (yalnızca meşru sunucu özel anahtara sahip olduğundan, diğer sunucular paylaşılan sırrın şifresini çözemez)
  5. İstemci, paylaşılan sır kullanılarak şifrelenen gerçek istek verilerini gönderir
  6. Sunucu istek verilerinin şifresini çözer, ardından şifreli bir yanıt gönderir
  7. İstemci yanıtın şifresini çözer ve kullanıcıya sunar.

Burada birkaç önemli noktaya dikkat edin:

  • Sertifika zinciri, istemcilerin, isteklerine müdahale eden birinin değil, konuştukları sunucunun gerçek olduğundan emin olmalarını sağlar. Bu nedenle gerçek bir SSL sertifikası satın almalısınız ve geçersiz, süresi dolmuş veya başka bir şekilde yanlış sertifika kullanan bir siteye geldiğinizde tarayıcılar size korkutucu uyarılar gönderiyor: Dünyadaki tüm şifreleme, yanlış kişiyle konuşuyor.
  • Sırrı değiştirmek için kullanılan genel / özel şifreleme, başarılı iletişimin yalnızca bu özel istemci ve sunucu çifti arasında çalışmasını sağlar: koklanan ağ paketleri şifrelenir ve verilere ulaşmak için sunucunun özel anahtarını gerektirir.
  • Özel / ortak anahtar şifrelemesinden çok daha düşük bir performans yükü olduğundan, isteğin büyük kısmı için simetrik şifreleme kullanılır. Anahtar (paylaşılan sır), özel / genel anahtar şifrelemesi kullanılarak değiştirilir, çünkü bunu güvenli bir şekilde yapmanın tek yolu budur (kurye hizmeti gibi ayrı bir kanal üzerinden taşımak dışında).

Açıkçası, bazı ek yükler var, ancak düşündüğünüz kadar kötü değil - kesinlikle büyük miktarda trafik için hazırlanmıyorsanız, çoğunlukla "ona daha fazla donanım atın" uygun yanıttır. Google veya Facebook düşünün). Normal şartlar altında, yani tipik web uygulaması kullanımı, SSL yükü ihmal edilebilir ve sonuç olarak, gizli verileriniz olur olmaz, kaynaklar dahil olmak üzere SSL üzerinde her şeyi çalıştırmak en iyisidir. SSL, HTTP trafiğini korumanın tek geçerli yoludur; diğer yöntemler basitçe standartlaştırılmamıştır ve bu nedenle yaygın olarak desteklenmemektedir ve kesinlikle bunları kendiniz uygulamak istemezsiniz, çünkü dürüst olmak gerekirse, onları yanlış yapmak çok kolaydır.

TL; DR: Evet, SSL + Temel Kimlik Doğrulama iyi bir fikir, evet, güvenli bir sunucuya (ve geçerli bir sertifikaya ) ihtiyacınız var, evet, işleri biraz yavaşlatacak, ama hayır, bu endişelenecek bir şey değil şimdi.


12

HTTPS (SSL) kullanıcı kimlik doğrulaması FYI değildir. Sadece 2 uç nokta arasında şifreleme sağlar.

Ama evet, ondan küçük bir ufacık yükü var (planlarda / donanımda bir değişikliği garanti etmek için yeterli olmasa da). Buraya bakın:

/programming/548029/how-much-overhead-does-ssl-impose


7
+1, küçük yükü göz önüne alındığında yeterince güvenli olmaktan çok daha güvenli olmak daha iyidir
Earlz

2
Bu cevap çok yanıltıcı. SSL olduğu bu sadece, kimlik doğrulama genellikle değil kullanıcı kimlik doğrulaması. SSL, konuştuğunuz sunucunun gerçekten söylediği kişi olduğunu doğrular. (CA'nın işi yalnızca facebook.com için Facebook'a sertifika vermektir.) Ayrıca SSL , istemci sertifikalarıyla kullanıcı kimlik doğrulaması yapabilir .
josh3736

@brian: josh3736 ile hemfikirim. SSL, kelimenin kriptografik anlamında kimlik doğrulaması sağlar. (Örn. Sunucu) kimlik doğrulaması olmadan orta saldırılarda insana açıksınız. SSL, akıllı kartları kullanarak güvenli istemci (kullanıcı) kimlik doğrulaması sağlayabilir veya sunucunun kimliğini doğruladıysa, güvenli kanal üzerinden başka araçlar (örn. Kullanıcı adı / şifre) kullanılabilir.
Guy Sirton

Gerçekten, OP'nin kullanıcı kimlik doğrulaması hakkında sorduğu ve istemcinin orta saldırılarda kiminle / kiminle konuştuğunu doğrulamasından endişe etmediği açıktı. Görevimi şiddetli bilgiçlik karşısında düzenledim;) Teknik olarak doğru, doğru, en iyi türdür
brian

6

HTTP temel kimlik doğrulaması ile, kullanıcının sağladığı kullanıcı adı ve parola sunucuya her istekle gönderilir. Bu, sitenizin güvenli olması gerekmeyen alanlarda bile düz metin halinde oldukları anlamına gelir. Açıkçası SSL'nin kullanıcılarınızı güvende tutmasını isteyeceksiniz.

Teorik olarak, çerez kimlik doğrulamasını kullanabilir ve giriş sayfasına yalnızca SSL (kullanıcı adı ve şifrenin gönderildiği yer) koyabilirsiniz. Çerezleriniz tekrar saldırılarına karşı oldukça güvenli ve güvenliyse, saldırgan bir tane almayı başarsa bile onlarla hiçbir şey yapamaz.


3

Temel kimlik doğrulama, http isteğinin başlığında bir kullanıcı adı ve parola ayarlamaktır. SSL veya eşdeğeri kullanmıyorsanız, bu kullanıcı adı ve şifre düz metin olarak gönderilir ve herkesin çalması önemsizdir.

Çoğu web sunucusu günümüzde HTTPS'yi kutudan çıkardığı gibi desteklemektedir ve her çağrıya ek yük getirmesine rağmen, ek yük minimumdur.

Bazı uç noktaları koruyabilirsiniz, diğerlerini değil (diğer aramalar için kullanılabilecek bir belirteç üreten kimlik doğrulaması uç noktasına sahip olabilirsiniz). SSL çok daha güvenli olsa da tüm hizmet için şiddetle tavsiye ediyorum. (başka bir şey yoksa hassas verilerin ele geçirilmesini durdurur)


Evet bence bu en iyi fikir. Web uygulamam kullanıcı oturumunu vb yönetecek, böylece jetonu orada kaydedebilir. Ama yine de birisi bu oturum için jetonu gizleyebilir mi? Veri güvenliği için hala bir risk olabilir
Gaz_Edge

Genel olarak evet. Çerezleri güvence altına almak için yapabileceğiniz şeyler vardır (yani şifrelemek), ancak daha basit ve daha etkili yol tüm siteyi güvence altına almaktır. Belirli bir kullanım durumunuz yoksa, en basit çözümü tavsiye ederim
Tom Squires

2

Jeff Atwood çok uzun zaman önce tam şifrelemenin gidip gitmeyeceği hakkında kısa bir blog yazısı yazdı . Bazı gerçek dünya örneklerini anlatıyor ve performans konusunda da birkaç çizgisi var.

Ayrıca, bir Gmail örnek olay incelemesi hakkında bu makaleye başvurarak aşağıdakileri alıntılar:

Bu yılın Ocak ayında (2010) Gmail, varsayılan olarak her şey için HTTPS kullanmaya başladı. Daha önce bir seçenek olarak tanıtılmıştı, ancak şimdi tüm kullanıcılarımız e-postalarını tarayıcıları ve Google arasında her zaman güvenceye almak için HTTPS kullanıyor. Bunu yapmak için ek makine ve özel donanım kullanmamalıydık. Üretim ön uç makinelerimizde SSL / TLS, CPU yükünün% 1'inden daha azını, bağlantı başına 10 KB'den daha az belleği ve ağ ek yükünün% 2'sinden daha azını oluşturur. Birçok kişi SSL'nin çok fazla CPU zamanı aldığını düşünüyor ve umarım yukarıdaki sayılar (ilk kez halka açık) bunu ortadan kaldırmaya yardımcı olacaktır.

Ayrıca , tarayıcı tarafından HTTPS aracılığıyla sayfaların istemci tarafında önbelleğe alınmasında son zamanlarda bazı iyileştirmelerden bahsediyor .

Buna rağmen, çoğu performans değil uygulama maliyetleri olan başka cezalar olduğuna dikkat çekiyor:

  • Zaten meşgul olan takımlar için ek karmaşıklık eklerken yazılım kalitesini korumak,
  • Proxy önbelleğe almanın düzgün yapılandırılması çok daha zordur ve kod değişikliklerine de ihtiyaç duyar,
  • Farklı kaynaklardan gelen içeriklerin bir araya getirilmesi için güvenliği doğru hale getirmek zor,
  • Düşük kaliteli mobil cihazlar şifreleme ile mücadele edebilir.

Lütfen yanıtınızı genişletin ve blogdaki bazı önemli noktaları ekleyin.
Walter

Blog gönderisinden önemli noktalar eklendi.
Daniel Dinnyes

0

Kendi oturum işlemeniz olmadan HTTP temel yetkilendirmesi, sizi Siteler arası istek sahteciliği saldırılarına açık bırakacaktır. Kendi oturum işlemenizle çiftlerseniz bunu kullanabilirsiniz, ancak temiz bir "oturumu kapat" işlevi sağlamada sorun yaşayabilirsiniz.

Kimlik doğrulama için ne kullanırsanız kullanın, bağlantıyı şifrelemek için HTTPS kullanmanız gerekecektir (web uygulamasına yalnızca kontrollü, güvenli bir ağda erişilmedikçe). İşleri biraz yavaşlatabilir (bağlantı kuruluşları pahalıdır, ancak tarayıcılar bağlantıları bir süre tutmaya eğilimlidir), ancak güvenli bir uygulama istiyorsanız, yine de bundan kaçınamayacaksınız, bu yüzden gerçekten ihtiyacınız yok endişelenmek için.

Not: "HTTPS kimlik doğrulaması" (başlıkta bahsettiğiniz) yanıltıcıdır - sorunuzun metniyle çok az ilgisi olan ve kendi yararları ve sorunları olan SSL istemci sertifikası kimlik doğrulaması anlamına gelebilir. Muhtemelen buna dokunmak istemezsiniz.


0

Temel kimlik doğrulamayı nasıl başaracaksınız?
Sabit kodlanmış bir kullanıcı adı / parola ise ve web sunucunuzun yerleşik işlevini kullanmak için kullanıyorsanız, büyük olasılıkla sıfıra yakın bir etkisi olacaktır. Bir veritabanında çılgın şeyler veya benzeri bir şey yapıyorsanız, evet bir etki olabilir.

Diğerlerinin burada belirttiği gibi, SSL ve ekstra başlıkların gönderilmesi teknik olarak işleri daha yavaş hale getirecek, ancak hiçbir şekilde önemli olmayacaktır.

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.