İnternetin geleceği HTTP 2.0 ne sunacak?

Günümüzdeki geniş bant hızlarının aslında yanıltıcı bir yanı var. Bazılarımız, sayfaları daha hızlı açabilmek ve indirme yapabilmek için 50 megabit ve üzeri hızlara para ödüyor. Ancak günlük hayatta bu tür hızlar, web sitelerini ADSL bağlantıya göre o kadar da hızlandırmıyor.

Daha hızlı bir internet için tüm ihtiyacımız, hızlı bir donanım ve hızlı bir bağlantıdan ibaret değil. Hala kullandığımız, ancak süresi geçmeye başlayan internet protokolleri, web tarayıcınız ve sunucu arasındaki iletişimi yavaşlatıyor. Çok basit HTML sayfalarının üretildiği, birkaç basit grafiğin kullanıldığı zamanlardan kalan bu protokoller, şu anki ağ iletişimi için çok geride kalıyor.

Günümüzün web sayfalarında yüzlerce satır koda, birçok farklı kaynaktan yüklenen web öğelerine rastlamanız oldukça muhtemel. Bu, sizinle web sunucusu arasında çoğunlukla kesintisiz bir iletişim gerektiriyor.

HTTP 1.1'den 2.0'a geçiş

Geride kalan protokoller için en iyi örnek HTTP. Web tarayıcısı ve sunucu arasındaki iletişimi yöneten bu merkezi uygulama protokolünün 1.1 sürümü, 1999'da ortaya çıkmıştı. 1.1 sürümünde bazı optimizasyonlar bulunsa da temel bir takım zafiyetler de var. Bu nedenle HTTP 1.1, bant genişliğini tam olarak değerlendiremiyor; dahası geniş "overhead" üretimi nedeniyle gereksiz ek trafik oluşturuyor.

Ağın teknik gelişiminden sorumlu Internet Engineering Task Force (IETF), 2012'den beri bu bağlantı protokolünün yenilenmesi üzerine çalışıyor. HTTP 2.0'ın yol haritası belli: Protokolün uzmanlara tanıtılmasının 2014'ün sonunda gerçekleşeceği düşünülüyor. Temmuz ayında bir taslağı yayınlanan protokolün ilk testlerine Ağustos'ta başlanmıştı.

SPDY, Speed+Mobility ve HTTP 2.0

SPDY, Speed+Mobility ve HTTP 2.0

Google ve Microsoft geçen sene HTTP 2.0 için kendi teknik geliştirmelerini teklif ettiler. Google'ın protokolü SPDY ve Microsoft'un Speed+Mobility'si, yeni HTTP için kıyasıya yarış içindeler.

Her iki protokol de HTTP 1.1'in hız sorunlarını çözmeye odaklanıyor. Ayrıldıkları ana nokta ise HTTP 2.0'ın verileri şifreleyerek aktarması konusunda. SPDY, HTTP 2.0'ın temelini oluşturmayı başarsa da zorunlu şifreleme işlevi IETF tarafından uygulanmıyor. Bunun nedeni şifrelemenin birçok mobil cihazda önemli bir işlem gücüne ihtiyaç duyması. Bu ise daha kısa pil ömrü anlamına geliyor. Dahası şifreleme, küçük web sitelerinin de işini zorlaştırıyor, çünkü sertifikaların bir maliyeti var.

Sadece güçlü bir şifrelemeye güvenilebilir

Eylül ayında NSA'nın (ABD Ulusal Güvenlik Ajansı) şifreli HTTPS trafiğini dinleyebildiği anlaşılmış, bu haber büyük yankı koparmıştı. Bir güvenlik uzmanı olan Bruce Schneier, bu durumu "ABD hükümetinin internete ihaneti" olarak değerlendirdi. Yaşananlar, HTTP 2.0'ın güvenliğini daha da ön plana çıkardı. Bu nedenle uzmanlar, HTTP 2.0'ın dinlememesi konusunda önemli yenilikler yapmayı planlıyorlar.

HTTPS, güvenli bir bağlantı kurmak üzere SSL ve TSL protokollerinden faydalanır. Bu, herkese açık ve özel bir anahtardan oluşan asimetrik bir bağlantıdır. Sunucu, web tarayıcısına sertifikalı, herkese açık bir anahtar gönderir. Tarayıcı sertifikanın kaynağını kontrol eder ve anahtarın geçerliliğini doğrular. Ardından oturum anahtarı, veri trafiği için bu anahtarla şifrelenir ve sunucuya gönderilir. Sunucu, simetrik şifrelemeyi sağlamak üzere elindeki özel anahtarı kullanarak bu mesajı açar. Artık sunucu ve web tarayıcısı aynı anahtara sahiptir ve aralarındaki veri iletişimi şifreli olarak gerçekleşebilir.

NSA arka kapısı

NSA arka kapısı

NSA'nın şifreli aktarımları çözmesi, tüm web trafiğini kaydedip, ardından bir mahkeme kararıyla sunucunun özel anahtarının hack'lenmesiyle gerçekleşebilir.

Böyle bir duruma karşı TLS 1.3'de, dolayısıyla HTTP 2.0'da farklı bir şifreleme yönteminin kullanılması teklif edilmişti. Buna göre yeni TLS şifreleme protokolü olan Perfect Forward Secrecy (PFS), direkt olarak anahtar değiş tokuşu yapmayacaktı. Bunun yerine sunucular ve web tarayıcıları, ortak bir simetrik anahtarı temel almayacak. Anahtar sadece bir oturumluk çalışacak ve oturumun ardından silinecek.

Ancak PFS'nin anahtar oluşturmada kullanacağı şifreleme yönteminin güvenli olması şart. NSA, geçmişte bu sürece aktif olarak katılmış ve göründüğü kadarıyla protokol içine arka kapılar yerleştirmiş. Asimetrik anahtar çifti için rastgele sayı üreten Dual_EC_DRBG'nin NSA'nın arka kapısını içerdiği ortaya çıkmıştı. NIST altında yayınlanan diğer sayı oluşturucuları üzerindeki şüpheler de devam ediyor. Simon Josefsson ise TLS 1.3 için kaynağı NIST olmayan, 25519 adında bir eliptik dalga öneriyor.

Ancak sadece yeni bir TLS protokolü de yeterli değil. HTTPS şifrelemesinde kullanılan, NSA'nın geliştirdiği RC4'ten de şüpheleniliyor. SSL 2.0 ve TLS 1.2'nin bir parçası olan RC4, şifreli web trafiğinin yüzde 50'sinde kullanılıyor. TLS 1.3 geldiğinde RC4 yerine onun kullanılacağını düşünüyor olabilirsiniz, ancak şu an itibariyle hangi protokolün kullanılacağını sunucu seçiyor. Chrome ve IE, en son sürüm olan TLS 1.2'yi kullansa da web sunucularının çoğu, geride kalmış SSL 3.0 veya TLS 1.0'ı tercih ediyor. Bu iki protokolde de bir saldırganın faydalanabileceği açıklar var. Dolayısıyla HTTP 2.0'da hangi protokolün kullanılacağını web tarayıcısının belirlemesi konusunda bir teklif var. Son olarak sitenin güvenli olup olmadığı ise kullanıcının tercihine bırakılacak.

SSL / TLS güvenlik açıkları

SSL / TLS güvenlik açıkları

Şu anki TLS saldırıları, paketlerin izlenebilmesine veya akıllıca değiştirilmesine dayanıyor. Bu konuda merkezi rolü Message Authentication Code (MAC) oynuyor. MAC, her pakette, oturum anahtarıyla beraber taşınıyor.

MAC, veri paketi ve oturum anahtarının karma değerinden oluşuyor. MAC sayesinde alıcı, verinin gerçekten gönderenden gelip gelmediğini belirleyebiliyor. Şu anki SSL, TLS gibi güvenlik protokollerinin tümü, "önce MAC, sonra şifreleme" prensibini benimsiyorlar. Bu ise şifreli paketin içeriğinin karma değerinin MAC oluşturmak üzere henüz kullanılmadığını gösteriyor.

Önce şifrele, sonra MAC gönder

Buna önlem olarak TLS uzantısının tersten çalıştırılması planlanıyor. Bu durumda şifreli paketin karma değeri kullanılıyor. Ancak bu önlemlerin paketleri izlenmeye gerçek anlamda engel olup olamayacağı henüz belirsiz.

En azından HTTP 2.0 trafiğinin her zaman şifreli olup olmayacağı konusu hala Internet Engineering Task Force'un düşünüp taşındığı konular arasında.

HTTP 2.0'ın performansı

HTTP 2.0'ın performansı

SPDY, HTTP 1.1'in yapısal yetersizliklerini kapatıyor: HTTP 1.1'in sunucuya kurduğu paralel bağlantılar, gereksiz trafik oluşturuyor. Head-of-line blocking adı verilen, paketlerin birbirini beklemesi durumu, yani verilerin talep edildiği sırayla gelmesi, yavaşlamaya katkıda bulunuyor. Bunun yanında HTTP bağlantıları her zaman istemci tarafından başlatılıyor. Bir web sitesinin değişip değişmediğini hep web tarayıcısının sorgulaması gerekiyor.

Ancak HTTPS 2.0'da web tarayıcısı ve sunucu, kendi veri akımlarını başlatabiliyorlar. HTTP 1.1'in aksine HTTP 2.0, paralelleştirmeyi tek bir TCP bağlantısı üzerinden gerçekleştiriyor. Bu, özellikle sunucu üzerindeki iş yükünü azaltıyor. Çerçevelere atanan öncelikler de web tarayıcının veya sunucunun sayfa öğelerini belirli bir sırayla yüklemesine izin veriyor. Head-of-line blocking sorunu ise HTTP 2.0'da yaşanmıyor. Dahası sunucu, web tarayıcısına push mesajları gönderebiliyor.

Optimize paket üstbilgisi

HTTP 1.1'de paket üstbilgileri, sıkıştırılmamış olarak gönderiliyor. Bu ise üstbilgilerin gereksiz biçimde büyük olması ve ikili kodla çözülmesi gerektiği anlamına geliyor. Sürüm 2.0 ise üstbilgiyi sıkıştırıyor ve ikili kod olarak gönderiyor. Bu sayede veri paketinin ilk çerçevesi önemli ölçüde küçülmüş oluyor ve veri, çok daha hızlı işlenebiliyor. Sonuç olarak gecikme süresi de önemli ölçüde azaltılmış oluyor.