İnternetin geleceği HTTP 20 ne sunacak?
HTTP 11'in yerini alacak, internetin geleceğini temsil eden HTTP 2 protokolü hakkında her şey!
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 11'den 20'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 11 sürümü, 1999'da ortaya çıkmıştı 11 sürümünde bazı optimizasyonlar bulunsa da temel bir takım zafiyetler de var Bu nedenle HTTP 11, 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), 2019'den beri bu bağlantı protokolünün yenilenmesi üzerine çalışıyor HTTP 20'ın yol haritası belli: Protokolün uzmanlara tanıtılmasının 2019'ü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 20
Google ve Microsoft geçen sene HTTP 20 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 11'in hız sorunlarını çözmeye odaklanıyor Ayrıldıkları ana nokta ise HTTP 20'ın verileri şifreleyerek aktarması konusunda SPDY, HTTP 20'ı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 ihanetiolarak değerlendirdi Yaşananlar, HTTP 20'ın güvenliğini daha da ön plana çıkardı Bu nedenle uzmanlar, HTTP 20'ı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'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 13'de, dolayısıyla HTTP 20'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 DualECDRBG'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 13 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 20 ve TLS 12'nin bir parçası olan RC4, şifreli web trafiğinin yüzde 50'sinde kullanılıyor TLS 13 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 12'yi kullansa da web sunucularının çoğu, geride kalmış SSL 30 veya TLS 10'ı tercih ediyor Bu iki protokolde de bir saldırganın faydalanabileceği açıklar var Dolayısıyla HTTP 20'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ı
Ş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 şifrelemeprensibini 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 20 trafiğinin her zaman şifreli olup olmayacağı konusu hala Internet Engineering Task Force'un düşünüp taşındığı konular arasında
HTTP 20'ın performansı
SPDY, HTTP 11'in yapısal yetersizliklerini kapatıyor: HTTP 11'in sunucuya kurduğu paralel bağlantılar, gereksiz trafik oluşturuyor Headofline 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 20'da web tarayıcısı ve sunucu, kendi veri akımlarını başlatabiliyorlar HTTP 11'in aksine HTTP 20, 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 Headofline blocking sorunu ise HTTP 20'da yaşanmıyor Dahası sunucu, web tarayıcısına push mesajları gönderebiliyor
Optimize paket üstbilgisi
HTTP 11'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 20 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
ve teknoloji
HTTP 11'in yerini alacak, internetin geleceğini temsil eden HTTP 2 protokolü hakkında her şey!
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 11'den 20'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 11 sürümü, 1999'da ortaya çıkmıştı 11 sürümünde bazı optimizasyonlar bulunsa da temel bir takım zafiyetler de var Bu nedenle HTTP 11, 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), 2019'den beri bu bağlantı protokolünün yenilenmesi üzerine çalışıyor HTTP 20'ın yol haritası belli: Protokolün uzmanlara tanıtılmasının 2019'ü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 20
Google ve Microsoft geçen sene HTTP 20 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 11'in hız sorunlarını çözmeye odaklanıyor Ayrıldıkları ana nokta ise HTTP 20'ın verileri şifreleyerek aktarması konusunda SPDY, HTTP 20'ı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 ihanetiolarak değerlendirdi Yaşananlar, HTTP 20'ın güvenliğini daha da ön plana çıkardı Bu nedenle uzmanlar, HTTP 20'ı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'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 13'de, dolayısıyla HTTP 20'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 DualECDRBG'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 13 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 20 ve TLS 12'nin bir parçası olan RC4, şifreli web trafiğinin yüzde 50'sinde kullanılıyor TLS 13 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 12'yi kullansa da web sunucularının çoğu, geride kalmış SSL 30 veya TLS 10'ı tercih ediyor Bu iki protokolde de bir saldırganın faydalanabileceği açıklar var Dolayısıyla HTTP 20'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ı
Ş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 şifrelemeprensibini 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 20 trafiğinin her zaman şifreli olup olmayacağı konusu hala Internet Engineering Task Force'un düşünüp taşındığı konular arasında
HTTP 20'ın performansı
SPDY, HTTP 11'in yapısal yetersizliklerini kapatıyor: HTTP 11'in sunucuya kurduğu paralel bağlantılar, gereksiz trafik oluşturuyor Headofline 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 20'da web tarayıcısı ve sunucu, kendi veri akımlarını başlatabiliyorlar HTTP 11'in aksine HTTP 20, 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 Headofline blocking sorunu ise HTTP 20'da yaşanmıyor Dahası sunucu, web tarayıcısına push mesajları gönderebiliyor
Optimize paket üstbilgisi
HTTP 11'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 20 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
ve teknoloji
