Private key kullanarak https çözümleme – 2

viewssld’nin nasıl çalıştığını daha iyi anlamak için önce ssl protokolünde verilerin nasıl şifrelendiğini anlamamız lazım.

Bir ssl bağlantısı temelde handshake ve application data flow diye tabir edeceğimiz iki ana kısımdan oluşur. Uygulama ile ilgili bilgilerin geçtiği application data flow kısmına geçmeden önce, tarafların bu verileri nasıl şifreleyecekleri konusunda bir anlaşmaya varmaları gerekir. Birbiri ile ilk kez iletişime geçen bu iki tarafın veri aktarımına geçmeden önce bağlantı hakkında emin olmaları gereken 3 konu bulunur.

Authenticity: Karşı tarafın gerçekten istenilen kişi olması. Genelde yalnızca server authentication yeterli olsa da, bazı durumlarda client’ın da kimliğini doğrulaması gerekebilir. Örneğin elinize bir mektup geçtiğinde bu mektubun gerçekten “Gönderen” kısmında belirtilen kişiden geldiğine emin olmanız gerekir.
Security: Aktarılan paketlerin yalnızca alıcı tarafından okunabilmesi. Paketleri sniff eden üçüncü bir kişi için bu veriler tamamen anlamsız olmalı. Elinizdeki zarfın başkası tarafından okunmamış olmasını istersiniz

Integrity: Verilerin karşı tarafa gönderildiği şekilde ulaşabilmesi. Araya giren herhangi birinin paketleri değiştirerek yollaması durumunda bu fark edilebilmeli. Bir zarfın açılmamış olması, bu zarfı son kapatan kişinin gönderen olduğunu garanti edemez. Başka birisi mektubu okuyup, hatta değiştirip yeniden kapatmış olabilir.

Handshake sırasında bu üç konunun nasıl çözüleceği cipher suite’ler kullanılarak belirlenir. Örneğin TLS_RSA_WITH_RC4_128_SHA kullanılıyorsa, kimlik doğrulama için RSA, şifreleme için RC4, veri doğrulama için SHA algoritmaları kullanılacak demektir. Bizim bu yöntemde ihtiyacımız olan, RSA dışında bir doğrulama yöntemi kullanılmamış olması. Şifreleme için kullanılan algoritma zaten OpenSSL tarafından çözüleceği için hangi algoritmanın kulllanılacağını tespit etmemiz yeterli olacak. Pasif saldırı yaptığımız için zaten integrity konusunda yapmamız gereken bir şey yok.

Önce Handshake sırasında gelişen olaylara bakalım:

Handshake ile ilgili detaylı bilgilere girmeyeceğim. Bizim için önemli olan konu, 11’de aktarılan encrypted mesajların nasıl decrypt edileceği. Bunun için bulmamız gereken temel bilgi ise 7’de oluşturulan Master Secret. Peki nedir bu Master Secret?

Master Secret; application data flow sırasında kullanılacak çeşitli key’lerin hesaplanması için kullanılan esas key olarak düşünülebilir. Pseudo Random Function denilen özel random fonksiyonları, belirli seed kelimelerle çalıştırılarak bu master secret‘dan farklı şifreler üretilir. Dolayısıyla veri aktarımının güvenliği için master secrethayati önem taşır.

Master Secret‘ın oluşturulmasını calculate_master_secret(client_random, server_random, pre_master_secret)şeklinde ifade edebililriz. Amacımız iki tarafta da aynı master secret ı oluşturmak olduğundan, client ve server birbirlerine rasgele oluşturulmuş veriler yollar. Böylece her bağlantıda farklı bir master oluşturulması sağlanır. Üçüncü parametre, pre_master_secret ise master_secret’ın yalnızca client ve server tarafından oluşturulmasını sağlar. Bu noktada bir adım daha ileri gidip pre_master_secret’ı aramamız gerekiyor.

PreMaster Secret (PMS); client tarafından oluşturulan, master secret‘ın gizliliğini temin eden 48 byte’lık bir şifre. Client PMS’i oluşturduğunda (4), Master Secret için gereken tüm veriler elinde hazır olmuş oluyor. Ancak PMS‘in güvenli bir şekilde server’a iletilmesi lazım. Bunun için de public-key cryptography(PKC) kullanılıyor. 2’de server’dan alınan sertifikanın içindeki public key kullanılarak şifrelenenen PMS, server’a gönderiliyor ve bu aşamadan sonra şifrelenerek gönderilen bütün verilerin güvenliği, bu şifrelenmiş PMS‘in yanlış ellere ulaşamayacağı varsayımına dayanmış oluyor. Biz de tam bu noktada araya giriyoruz!

Public-key algoritmalarının temeli şuna dayanır: Bir veriyi herkes bir public-key kullanarak şifreleyebilir. Dolayısıyla public-key’in gizliliği önemli değildir. Ama bu şifrelenmiş veri yalnızca o public-key’e karşılık gelen private-key tarafından çözülebilir. Yani server’ın sertifikasında kullandığı public-key’e karşılık gelen private-key elimizdeyse, önce pre-master-secret’ı, sonra master-secret’ı daha sonra da application data flow sırasında gereken tüm şifreleri hesaplamamız mümkün demektir.

Tabi facebook, gmail gibi şirketler kolayca private-key lerini paylaşmayacaktır. Dolayısıyla bu yöntemin kullanılabilirliği tartışılır.
Peki ya client’a gelen sertifikadaki public-key aslında facebook’un değil, bizim private-key’imize ait public-key ise??

sıra geldi MITM’e..

Salih AHİ

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s