Hypertext Transfer Protocol Secure (HTTPS)

Hypertext Transfer Protocol Secure (HTTPS)

HTTP’nin en büyük dezavantajlarından biri, tüm verilerin clear-text (şifrelenmemiş) olarak iletilmesidir. Bu da kaynak ile hedef arasında bulunan herhangi bir kişinin Man-in-the-middle (MiTM) saldırısı gerçekleştirerek aktarılan verileri görüntüleyebilmesi anlamına gelir.

Bu sorunu çözmek için HTTPS (HTTP Secure) protokolü geliştirilmiştir. HTTPS’te tüm iletişim şifreli (encrypted) olarak aktarılır. Böylece üçüncü bir taraf isteği ele geçirse bile, içindeki verileri okuyamaz veya çıkaramaz.

Bu nedenle HTTPS, internet üzerindeki web siteleri için ana akım (mainstream) hâline gelmiştir. HTTP ise aşamalı olarak terk edilmektedir ve çok yakında çoğu web tarayıcısı HTTP sitelere erişime izin vermeyecektir .

HTTPS Overview

Bir HTTP request’i incelediğimizde, web browser ile web application arasında güvenli iletişim zorunlu tutulmadığında ortaya çıkan riskleri açıkça görebiliriz.

Örneğin, aşağıda bir HTTP login request ’inin içeriği yer almaktadır:

Görüldüğü üzere, login credentials clear-text (şifrelenmemiş) olarak görüntülenebilmektedir. Bu durum, aynı ağda bulunan birinin (örneğin public wireless network ) isteği kolayca yakalayıp credentials ’ları kötü amaçlı kullanabilmesini mümkün kılar.

Buna karşılık, bir HTTPS request ’ine ait trafiği birisi yakalayıp analiz ettiğinde, aşağıdakine benzer bir görüntüyle karşılaşır:

Görüldüğü gibi, veriler tek bir şifreli (encrypted) akış hâlinde iletilmektedir. Bu da credentials veya diğer hassas verilerin yakalanmasını son derece zorlaştırır.

HTTPS’i zorunlu kılan web siteleri , URL’lerinde bulunan https:// ifadesiyle (örneğin https://www.google.com ) ayırt edilebilir. Ayrıca web tarayıcısının adres çubuğunda, URL’nin sol tarafında yer alan kilit simgesi de sitenin HTTPS kullandığını gösterir.

Dolayısıyla, Google gibi HTTPS kullanan bir web sitesini ziyaret ettiğimizde, tüm trafik şifreli (encrypted) olur.

Not: HTTPS protokolü üzerinden aktarılan veriler şifreli olsa bile, eğer istek clear-text bir DNS server üzerinden çözülüyorsa, ziyaret edilen URL yine de açığa çıkabilir . Bu nedenle, encrypted DNS server kullanılması (örneğin 8.8.8.8 veya 1.1.1.1 ) ya da tüm trafiğin doğru şekilde şifrelenmesini sağlamak için bir VPN service kullanılması önerilir.

HTTPS Flow

Şimdi HTTPS’in yüksek seviyede (high level) nasıl çalıştığına bakalım:

HTTPS’i zorunlu kılan bir web sitesini ziyaret ederken https:// yerine http:// yazarsak, tarayıcı önce domain’i çözümlemeye çalışır ve kullanıcıyı hedef web sitesini barındıran web server’a yönlendirir. İlk olarak şifrelenmemiş HTTP protokolü olan port 80 ’e bir request gönderilir. Sunucu bunu algılar ve istemciyi güvenli HTTPS portu olan 443 ’e yönlendirir.

Bu yönlendirme, ilerleyen bölümlerde ele alacağımız 301 Moved Permanently response code ile gerçekleştirilir.

Sonrasında istemci (web browser), kendisi hakkında bilgi içeren bir “client hello” paketi gönderir. Bunun ardından sunucu “server hello” ile yanıt verir ve SSL certificates ’ların değiş tokuş edildiği bir key exchange süreci başlar.

İstemci, sunucudan gelen key/certificate ’ı doğrular ve kendi sertifikalarından birini gönderir. Bundan sonra, şifrelemenin ve veri aktarımının doğru çalıştığını teyit etmek için encrypted handshake başlatılır.

Handshake başarıyla tamamlandıktan sonra, normal HTTP communication devam eder; ancak bu noktadan itibaren tüm iletişim şifreli (encrypted) olarak gerçekleşir. Bu anlatım, key exchange sürecinin çok yüksek seviyede bir özetidir ve detayları bu modülün kapsamı dışındadır.

Not: Bazı durumlarda bir saldırgan, HTTP downgrade attack gerçekleştirebilir. Bu saldırı, HTTPS iletişimini HTTP’ye düşürerek aktarılan verilerin clear-text hâline gelmesini sağlar. Bu genellikle, kullanıcının bilgisi olmadan tüm trafiği saldırganın makinesi üzerinden geçiren bir Man-In-The-Middle (MITM) proxy kurulmasıyla yapılır.

Ancak günümüzdeki çoğu modern tarayıcı, sunucu ve web application bu tür saldırılara karşı koruma sağlamaktadır.

cURL for HTTPS

cURL, HTTPS iletişimi için gerekli tüm standartları otomatik olarak yönetir; secure handshake gerçekleştirir ve verileri otomatik olarak şifreleyip çözer.

Ancak geçersiz (invalid) veya süresi dolmuş (outdated) bir SSL certificate kullanan bir web sitesine bağlanmaya çalışırsak, cURL varsayılan olarak iletişimi devam ettirmez . Bu davranış, yukarıda bahsedilen MITM attacks ’lere karşı bir güvenlik önlemidir.

curl https://inlanefreight.com

curl: (60) SSL certificate problem: Invalid certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html
...SNIP...

Modern web tarayıcıları da aynı şekilde davranır ve geçersiz bir SSL certificate kullanan bir web sitesini ziyaret etmeye çalıştığımızda kullanıcıyı uyarır.

Bu tür bir problemle özellikle:

- local bir web application test ederken

- ya da practice amaçlı barındırılan web uygulamalarında

karşılaşabiliriz. Çünkü bu tür uygulamalarda genellikle geçerli bir SSL certificate henüz yapılandırılmamış olabilir.

cURL ile certificate kontrolünü atlamak için -k parametresi kullanılabilir:

curl -k https://www.inlanefreight.com
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
...SNIP...

Görüldüğü gibi, bu sefer request başarıyla gönderildi ve response data alındı.