Pengamanan serangan Man-in-the-Middle pada Mobile Application menggunakan metode Certificate Pinning

Standard

Mungkin ada beberapa dari Anda yang sudah membaca artikel tentang security vulnerability pada aplikasi Gojek dan Bank Mandiri isi ulang e-Money berbasis NFC yang ditulis oleh Yohanes Nugroho pada link berikut:

Gojek : http://blog.compactbyte.com/2016/01/02/bug-gojek-agustus-2015/

Bank Mandiri: http://blog.compactbyte.com/2016/01/02/bug-mandiri-e-money-isi-ulang-november-2015/

Pada kedua artikel tersebut, Pak Yohanes Nugroho melakukan analisis terhadap data yang dikirimkan dan diterima oleh aplikasi tersebut. Sedangkan untuk dapat mengetahui data yang dikirimkan dan diterima oleh aplikasi, terdapat beberapa cara yaitu:

  1. Menggunakan HTTP/HTTP debugger proxy seperti Fiddler, Burp Proxy, OWASP ZAP Proxy dan tools lain sejenisnya dengan metode MiTM
  2. Melakukan static analysis dengan membaca source code yang telah di-decompile (reverse engineering)
  3. Melakukan Log Analysis

Saya telah menanyakan terkait cara yang digunakan Pak Yohanes Nugroho melalui komentar di artikel beliau, namun saat artikel ini ditulis, Pak Yohanes Nugroho belum memberikan balasan. Jadi, mari kita bersasumsi bahwa cara pertama lah yang digunakan.

Seperti pada artikel yang Saya tulis sebelumnya : https://adefirmantriangga.wordpress.com/2016/08/01/dekripsi-https-menggunakan-fiddler-dan-dampaknya-pada-mobile-application/

Man-in-the-Middle pada HTTPS traffic ini dapat terjadi karena aplikasi yang berperan sebagai Client, “mempercayai” semua Certificate yang dikirimkan oleh Server, aplikasi tidak melakukan verifikasi terhadap Certificate, apakah Certificate tersebut diterbitkan oleh Certificate Authority yang sah atau tidak.

pinning-fig-2

sumber gambar: https://blogs.mcafee.com/wp-content/uploads/pinning-fig-2.jpg

Apa itu Certificate Pinning?

Secara default, saat sebuah Client akan terkoneksi menggunakan SSL, Client akan akan mengecek beberapa hal, seperti:

  1. Apakah certificate memiliki “chain of trust” ke trusted root certificate
  2. Apakah certificate tersebut memiliki requested hostname yang match

Nah, kemudian muncul pertimbangan:

Kalau Client memang hanya berkomunikasi dengan Server yang spesifik dan tertentu dalam setiap koneksi, kenapa tidak kita definisikan Certificate-nya secara spesifik sesuai dengan Server yang spesifik dan tertentu tersebut? 

Certificate Pinning adalah solusinya

Certificate Pinning dilakukan dengan mendefinisikan Certificate secara Hard-Code pada aplikasi, sehingga sifatnya statis. Aplikasi dapat mengacuhkan Trust Store pada Perangkat dan bergantung pada Trust Store sendiri. Dengan demikian, Aplikasi hanya mau berkoneksi apabila Certificate yang dikirimkan oleh Server, “MATCH” dengan Certificate yang di-hard code tersebut.

(Reminder: Trust Store sederhananya berisi daftar Certificate Authority yang dapat “dipercaya”. Sistem Operasi dan Aplikasi memiliki Trust Store sendiri-sendiri)

Mengapa aplikasi harus memiliki Trust Store sendiri??? Jawabannya adalah karena Trust Store pada perangkat, atau pada Android OS mudah sekali di”susupi” oleh Certificate yang berbahaya dan tidak diterbitkan oleh pihak yang semestinya.

Analogi sederhana tentang Certificate Pinning ini misalnya sebagai berikut:

Budi kita analogikan Client / Aplikasi, 

mari kita analogikan apabila aplikasi tidak menerapkan SSL secara optimal dan menerapkan parameter org.apache.http.conn.ssl.AllowAllHostnameVerifier atau SSLSocketFactory.ALLOWALLHOSTNAME_VERIFIER. pada aplikasi.

  1. Budi seorang siswa Sekolah Dasar, setiap hari ia dijemput Orang Tua nya.
  2. Namun hari ini, Budi diinformasikan oleh Orang Tuanya bahwa kedua Orang Tuanya tidak bisa menjemput Budi.
  3. Orang Tua Budi mengutus Andi yang merupakan saudara, untuk menjemput Budi.
  4. Saat ini, Budi belum pernah bertemu dengan Andi
  5. Sehingga apabila ada Penculik yang mengaku sebagai Andi, Budi akan percaya dan ikut dengan si Penculik dan menjadi korban penculikan.

Hal ini tidak akan terjadi apabila Orang Tua Budi, mengirimkan foto Andi sebagai orang yang akan menjemput Budi di sekolah. atau paling tidak, Orang Tua Budi memberikan ciri-ciri yang jelas seperti apa Andi, misalnya warna rambut, warna kulit, bentuk rambut. dll.

Budi tidak akan terbujuk oleh si Penculik dan hanya akan ikut pergi apabila yang mengajak adalah seseorang yang benar, yaitu Andi.

Mungkin penjalasan diatas bisa digunakan untuk menganalogikan Certificate Pinning, memberikan informasi terlebih dahulu kepada Budi (Client) terkait ciri-ciri Andi si Penjemput dengan detil, baik menggunakan foto atau ciri-ciri fisik yang dijelaskan, mirip seperti pendefinisian Certificate secara hard-code pada aplikasi dalam implementasi Certificate Pinning.

Kelebihan

  1. Menambah Keamanan Aplikasi. – Certificate Pinning memang butuh effort lebih, tidak semua aplikasi harus mengimplementasikan metode ini, hanya aplikasi dengan tingkat kritikalitas yang tinggi seperti aplikasi banking, financial, dan beberapa game yang direkomendasikan untuk mengimplementasikan metode ini.
  2. Mengurangi Cost – Sebenarnya ada metode lain untuk menutup celah keamanan terkait penerapan SSL yang tidak optimal seperti yang dijelaskan sebelumnya, yaitu dengan menggunakan Certificate Berbayar yang diterbitkan oleh Certificate Authority yang komersil seperti Symantec, Comodo, Digicert dll. Ya, namun ini berbayar, berbeda dengan Certificate Pinning. Anda dapat menggunakan Self-Sign Certificate (Certificate yang diterbitkan oleh Server anda sendiri) sehingga tidak perlu berbayar, syaratnya anda harus mendefinisikan juga secara hard-code bahwa Server anda masuk sebagai Certificate Authority yang dapat dipercaya, dalam istilah umum, ini biasa disebut “Unknown CA” bagaimana caranya? dapat anda lihat disini: https://developer.android.com/training/articles/security-ssl.html#UnknownCa

Hal ini sudah umum dilakukan oleh organisasi dan perusahaan tertentu, seperti University of Washington. Contoh implementasi Certificate Pinning yang dilakukan oleh University of Washington dapat dilihat disini juga: https://developer.android.com/training/articles/security-ssl.html#UnknownCa

Kekurangan

  1. Kurang Fleksibel – dalam suatu kondisi, anda ingin mengubah SSL certificate pada aplikasi anda. Untuk melakukan ini, anda harus mengupdate aplikasi anda, upload ke Google Play dan “memaksa” User untuk mengupdate dan menginstall aplikasi yang baru. Jika tidak, Pengguna aplikasi yang lama tidak akan bisa terkoneksi karena Certificate yang sudah tidak lagi “MATCHED”
  2.  Perlu Pengamanan Lebih – masih ada ancaman yang harus dihadapi ketika anda “menanam sesuatu” secara hard-code pada aplikasi, yaitu Reverse Engineering. Metode, tools, dan penjelasan mengenai Reverse Engineering pada aplikasi Android sudah sangatlah populer, Sehingga ada potensi ancaman seorang Hacker untuk mengubah source code untuk membypass Certificate Pinning ini, entah dengan mengubah Logic, mengubah Keystore atau yang lainnya. Sehingga Developer perlu menerapkan pengamanan lebih untuk memproteksi binary aplikasi dan mencegah Reverse Engineering seperti code obfuscation, encryption, dan lain-lain

 

Seperti yang tertulis pada artikel yang ditulis oleh Pak Yohanes Nugroho, banyak sekali serangan lanjutan dan informasi yang didapatkan apabila seorang attacker telah mengetahui apa yang dikirim dan diterima oleh aplikasi. seperti replay attack, informasi bug-bug lain seperti pada session, otentikasi dan lainnya juga dapat diketahui.

 

 

Sumber dan Referensi:

Certificate Pinning Implementation Sample: https://github.com/ikust/hello-pinnedcerts

Official Android Explanation related to SSL Implementation: https://developer.android.com/training/articles/security-ssl.html#UnknownCa

OWASP Certificate & Public Key Pinning Guide: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

Infinum SSL Certificate Pinning Implementation Article: https://infinum.co/the-capsized-eight/articles/securing-mobile-banking-on-android-with-ssl-certificate-pinning

 

Disclaimer:

Semua tulisan Saya adalah berdasarkan eksplorasi dan pemahaman Saya yang terbatas sejauh ini, Pembaca bebas memberikan masukan apabila ada yang kurang tepat. CMIIW abis lah pokoknya.

Advertisements

Dekripsi HTTPS menggunakan Fiddler dan Dampaknya pada Mobile Application

Standard

Oke, HTTPS atau HTTP over SSL diciptakan untuk mencegah traffic sniffing dan tampering. Terus, kok bisa di dekripsi? gimana caranya?

Kali ini Saya akan menggunakan tools bernama Fiddler (download link di akhir artikel), Saya tidak akan menjelaskan bagaimana cara untuk mendekripsi sebuah traffic HTTPS, namun lebih kepada bagaimana sebuah traffic HTTPS dapat didekripsi oleh Fiddler

Bagaimana bisa Fiddler ini mendekripsi traffic HTTPS?

Ada baiknya sebelum membaca artikel ini lebih lanjut, anda membaca artikel terkait bagaimana SSL bekerja dan bagaimana SSL Handshake dibangun di link ini: https://adefirmantriangga.wordpress.com/2016/08/01/apa-itu-ssl/

Fiddler menggunakan teknik/metode man-in-the-middle attack untuk mengintercept traffic sebuah koneksi HTTPS.

Kepada aplikasi, Fiddler berpura-pura menjadi web server yang dituju. dan Kepada Web Server yang dituju, Fiddler berpura-pura sebagai aplikasi/browser yang akan mengakses. Penjelasan ini diilustrasikan dengan gambar dibawah ini.

Main_the_middle

Secara dinamis, Fiddler menghasilkan Fake Certificate guna menjalankan tipu muslihat ini kepada Client (baik web browser maupun aplikasi).

Ingat Kembali! Ketika Client akan berkoneksi kepada suatu Server, Client akan meminta Server untuk mengirimkan certificate tersebut kepada Client. Sesuai Gambar diatas, ketika Fiddler mengidentifikasi adanya Client yang meminta Certificate kepada Server, Attacker (Fiddler) langsung mengirimkan Fake Certificate kepada Client, sehingga koneksi pun terjadi.

SSL Handshake ini dimanfaatkan oleh Fiddler, ketika sebuah Client meminta identitas berupa Digital Certificate ke Server, Server mengirimkan Digital Certificate yang didalamnya juga terdapat Public Key server tersebut untuk mengenkripsi data yang akan dikirimkan oleh Client. Client tidak menyangka bahwa yang mengirimkan Digital Certificate Public Key itu bukanlah Server yang sebenarnya dituju, melainkan Fiddler yang berpura-pura menjadi server melalui teknik MitM diatas. Secara otomatis, Fiddler dapat mendekripsi data yang dikirimkan oleh Client menggunakan Private Key yang dimilikinya walaupun datanya telah dienkripsi sebelumnya, jelas saja wong Public Key yang digunakan untuk Enkripsi itu Public Key-nya Fiddler. (ingat kembali konsep Asynchronous Cryptography atau Public key – Private Key Cryptography)

Untuk mendekripsi traffic HTTPS anda cukup masuk ke menu Tools > Fiddler Options > HTTPS > Decrypt HTTPS

Memang, untuk membuat koneksi diatas memungkinkan dalam sebuah real-world scenario, hal tersebut agak susah dilakukan, karena kita harus masuk ke perangkat korban dan set-up proxy perangkat korban agar diarahkan ke IP Address komputer kita. Namun hal itu dapat dilakukan juga secara anonymous menggunakan teknik ARP Poisoning atau APR menggunakan Tools seperti Cain & Abel yang dilakukan kepada Router / Access Point.

Oke kembali lagi ke FIddler, Karena Fiddler memproduksi Fake Certificate dan bukanlah sebuah Certificate yang diterbitkan oleh Trusted Root Certificate Authority, Browser anda tidak akan mengenali Certificate yang dikirim oleh Attacker (Dengan asumsi bahwa Attacker adalah pengguna Fiddler). Ketika sebuah browser tidak mengenali Certificate Authority yang terdapat pada Digital Certificate, Browser akan memunculkan sebuah warning seperti gambar dibawah ini:

IE Cert Error

Lho? kok bisa?

Setiap browser memiliki daftar Certificate Authorities yang secara default telah terdapat pada paket instalasi browser tersebut, Berikut adalah contoh daftar Certificate Authority yang telah terdaftar secara default oleh Mozilla: https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport

Sehingga, apabila ada sebuah server yang mengirimkan digital certificate yang diterbitkan oleh Certificate Authorities diluar daftar diatas, browser akan mengeluarkan peringatan.

Nah, hal diatas juga berlaku pada Mobile Platform khususnya Android, Android juga telah memiliki daftar Certificate Authorities yang secara default seperti pada link ini http://www.andreabaccega.com/blog/2010/09/23/android-root-certification-authorities-list/

Untuk dapat melanjutkan browsing dengan kondisi munculnya Pop Up pada browser seperti gambar diatas, User harus mengklik “Add Security Exception” atau “Proceed blablabla unsafe” (Saya lupa kata-kata persisnya)

Oke, sekarang bagaimana caranya supaya Client tidak mengeluarkan peringatan pada browser, pada sistem operasinya (khususnya android dan windows seperti gambar dibawah ini)? Caranya adalah dengan menginstall certificate tersebut dan membuatnya terdaftar sebagai “Trusted” di device kita.

Catatan: selain pada browser/aplikasi, sistem operasi pun juga memiliki daftar Certificate Authorities yang dipercaya. seperti pada Windows, disebut dengan Windows Trust Store / Windows Certificates Store

Windows Trust Prompt

Install/Trust Fake Certificate pada Windows

fdEDM

Install/Trust Fake Certificate pada Android.

Saktinya, Fiddler melakukan dekripsi melalui fake certificate ini secara on-the-fly, artinya Kita tidak perlu melakukan instalasi certificate ke Certificate Store / Trust Store pada perangkat kita. Tidak seperti tools-tools lain seperti Burp Proxy, OWASP ZAP, dll. Mungkin ada suhu-suhu yang baca artikel ini, bisa memberi masukan lebih detil kenapa Fiddler tidak perlu install Certificate seperti tools-tools diatas yang Saya sebutkan.

Nah Sayangnya, aplikasi android yang bertindak sebagai “browser” untuk berkoneksi dengan server, masih banyak yang menggunakan Self Signed Certificate, alias Certificate yang tidak memerlukan verifikasi karena di-verifikasi sendiri. tidak melalui Trusted Root CA

Dengan metode MitM seperti yang dijelaskan diatas, seorang Attacker dapat melihat data yang dikirimkan oleh aplikasi kepada server secara cleartext seperti layaknya HTTP traffic biasa dan ini tentunya sangat berbahaya.

 

Masih banyak aplikasi android yang rentan terhadap hal ini dengan masih mengimplementasikan fungsi org.apache.http.conn.ssl.AllowAllHostnameVerifier atau SSLSocketFactory.ALLOWALLHOSTNAME_VERIFIER. Ini sama saja dengan mempercayai semua certificate yang diberikan oleh Server kepada Client. sekalipun oleh entitas yang ngaku-ngaku sebagai server seperti Fiddler ini, berikut adalah contoh Certificate yang diberikan oleh Fiddler:

 

Untuk mencegah Man-in-the-Middle menggunakan Fake Certificate seperti ini, Android memiliki teknik pengamanan yang disebut dengan Certificate Pinning.

Penjelasan lebih lengkap mengenai Certificate Pinning dapat dibaca di artikel Saya disini:

Intinya, teknik ini mendefinisikan Certificate yang dinilai Trusted secara benar-benar spesifik pada source code aplikasi (hardcoded). Artinya kalau Certificate yang ditawarkan Server tidak sama dengan Certificate yang telah didefinisikan secara spesifik pada Source Code aplikasi, maka Koneksi tidak akan terjadi antara aplikasi dengan server. If you dont trust the Server, don’t establish the connection.

Saya sudah mencoba hampir semua aplikasi mobile milik perusahaan-perusahaan Tech Startup di Indonesia, dan hampir semuanya sudah mengimplementasikan teknik ini. Sebut saja Gojek, Grab, Traveloka, Bukalapak, Tokopedia, Lazada, dll.


Biasanya, apabila kita melakukan MitM menggunakan Fiddler pada aplikasi-aplikasi yang telah menerapkan Certificate Pinning, akan ada popup seperti “Koneksi gagal” “Gangguan Jaringan” dsb, karena memang aplikasi tidak mau terkoneksi kalau Certificate yang ditawarkan oleh Server tidak “Match” dengan apa yang ada di Source Code.

Penutup

Oke, apakah sebenarnya yang dilakukan Fiddler? apakah Fiddler ini sebenarnya menunjukkan vulnerability dan security holes pada HTTPS / SSL? Jawabannya TIDAK. Karena sebenarnya Kita (User) sudah diperingatkan browser apabila ada Untrusted Connection yang ingin berkoneksi dengan kita. Kalau User tetap ngeyel dan memilih “proceed” atau “Add to Security Exception”, ya itu sih Usernya yang salah dan ga aware.

Human is the weakest link in the Security Chain, makanya ada yang bilang sebenarnya sumber insiden keamanan itu penyebabnya dari Layer 8, alias manusianya itu sendiri. memang, Security Awareness Program is really really important.

 

 

 

Nice to Know:

Apa itu SSL: https://adefirmantriangga.wordpress.com/2016/08/01/apa-itu-ssl/

Apa itu Certificate Authority: https://adefirmantriangga.wordpress.com/2016/08/01/apa-itu-certificate-authority-ca/

Apa itu Digital Certificates: https://adefirmantriangga.wordpress.com/2016/08/01/apa-itu-digital-certificates/

 

Sumber dan Referensi:

Fiddler Download Page: https://www.telerik.com/download/fiddler

How Fiddler Works: http://www.enhanceie.com/fiddler/help/httpsdecryption.asp

Decrypting Using Fiddler: https://thetechl33t.com/2014/07/12/decrypting-https-ssltls-tunnels-using-fiddler/

Android Transport Layer Security: https://manifestsecurity.com/android-application-security-part-10/

 

Disclaimer:

Semua tulisan Saya adalah berdasarkan eksplorasi dan pemahaman Saya yang terbatas sejauh ini, Pembaca bebas memberikan masukan apabila ada yang kurang tepat. CMIIW abis lah pokoknya.

Apa itu Certificate Authority (CA)?

Standard

Certificate Authority adalah entitas terpercaya yang menerbitkan sebuah dokumen elektronik yang memverifikasi suatu identitas dari suatu entitas di internet, dokumen elektronik yang dimaksud adalah Digital Certificate.

Digital Certificate sendiri memuat informasi terkait nama penerbit Certificate tersebut (CA).

Saat ini, Sistem Operasi dan Web Browser secara default sudah memiliki daftar Certificate Authority, sehingga apabila terdapat Certificate yang diterbitkan oleh CA diluar yang ada pada daftar default di Sistem Operasi dan Web Browser, peringatan akan muncul seperti pada Gambar dibawah ini:

IE Cert Error

Windows Trust Prompt

Apabila di-analogikan, CA ini seperti layanan pihak berwajib, katakanlah Kepolisian dan Digital Certificates ini adalah STNK.

Misalnya, Saya memiliki parkiran yang sebelum masuk, harus dipastikan dulu bahwa STNK yang diberikan oleh kendaraan yang akan masuk adalah STNK yang Valid dan Asli.

Pada Suatu hari, Bedjo ingin parkir di parkiran Saya, Untuk memastikan STNK ini asli, kita harus menghubungi Kepolisian atau Samsat untuk memeriksa apakah STNK ini valid milik Bedjo atau telah dipalsukan. Hal ini dilakukan karena Kepolisian/Samsat lah yang menerbitkan STNK tersebut dan untuk menghindari adanya kendaraan dengan STNK palsu yang berhasil masuk parkiran Saya.

 

Sumber dan Referensi: 

Certificate Authority: http://searchsecurity.techtarget.com/definition/certificate-authority

Disclaimer:

Semua tulisan Saya adalah berdasarkan eksplorasi dan pemahaman Saya yang terbatas sejauh ini, Pembaca bebas memberikan masukan apabila ada yang kurang tepat. CMIIW abis lah pokoknya.

Apa itu Digital Certificates?

Standard

Seperti layaknya passport, Digital Certificate memuat informasi yang bersifat mengidentifikasikan entitas yang dimaksud.

Digital Certificate dapat diverifikasi karena diterbitkan langsung oleh Certificate Authorities.

Digital Certificate memuat informasi-informasi seperti Nama Pemegang Certificate, Serial Number, Tanggal Kadaluwarsa, Public Key, serta Digital Signatures dari CA.

Berikut adalah contoh dari Digital Certificate:

Ketika sebuah koneksi HTTPS terjadi, Web Server terkait akan mengirimkan informasi seperti diatas kepada Web Browser.

Web Browser kemudian akan memverifikasi Digital Certificate ini kepada Comodo Individual Subscriber Class 1 CA seperti yang tertera pada gambar diatas. Apabila Certificate tersebut dinyatakan Valid dan Match oleh Certificate Authority, maka barulah koneksi HTTPS akan terjadi antara Web Browser dan Web Server tersebut.

 

Sumber dan Referensi: 

Digital Certificate: http://searchsecurity.techtarget.com/definition/digital-certificate

 

Disclaimer:

Semua tulisan Saya adalah berdasarkan eksplorasi dan pemahaman Saya yang terbatas sejauh ini, Pembaca bebas memberikan masukan apabila ada yang kurang tepat. CMIIW abis lah pokoknya.

 

 

Apa itu SSL?

Standard

Apa itu SSL? Kenapa harus SSL?

SSL adalah kepanjangan dari Secure Socket Layer. SSL ini adalah standar keamanan untuk menyediakan koneksi yang aman antara client dan server.

Client seperti apa yang dimaksud? dapat berupa web browser, aplikasi desktop, atau aplikasi mobile.

SSL sendiri merupakan pengamanan terhadap koneksi HTTP, maka dari itu, HTTP yang telah dilengkapi SSL disebut dengan HTTPS, atau HTTP over SSL atau HTTP Secure atau Secure HTTP.

SSL ini dibutuhkan karena melalui koneksi biasa (HTTP), data-data yang dikirimkan antara server dan client ditransmisikan dalam keadaan cleartext alias tidak terenkripsi.

Apabila Kita flashback sedikit ke konsep dasar security, melalui SSL kita dapat menjamin kerahasiaan (Confidentiality) dan integritas (Integrity) atas data-data yang ditransmisikan tersebut (data-in-transit)

Untuk website atau aplikasi yang mentransmisikan data-data yang bersifat sensitif atau rahasia. SSL sangatlah dibutuhkan untuk menjaga integritas data yang dikirimkan.

Salah satu (salah dua) ancaman keamanan yang coba dicegah oleh SSL adalah Sniffing dimana seorang hacker dapat menyadap koneksi antara client dan server tersebut (eavesdropping) dan Man-in-the-Middle attack dimana seorang hacker dapat meng-intercept koneksi antara client dan server tersebut, dan biasanya. merubah apa yang dikirimkan antara client dan server tersebut.

BasicSSLConnection.jpg

Lalu bagaimana SSL ini bekerja? bagaimana caranya?

Seperti yang telah dijelaskan diatas, SSL menyediakan koneksi yang aman dan terenkripsi antara client dan server. Berikut koneksi SSL antara client dan server tersebut secara sequential (bahasa penjelasan dibawah agak dibuat sesederhana mungkin dengan maksud lebih mudah dipahami) :

  1. Sebuah browser/aplikasi desktop/aplikasi mobile mencoba mengkoneksikan ke sebuah server dengan pengamanan berupa SSL,
  2. Browser/aplikasi desktop/aplikasi mobile tersebut meminta server untuk menunjukkan identitasnya (SSL certificate)
  3. Server mengirimkan copy dari SSL certificate yang dimiliki oleh Server
  4. Browser mengecek apakah SSL certificate yang dikirim oleh Server tadi merupakan Certificate yang dapat dipercaya. Jika ya, Browser mengirim pesan kepada Server
  5. Server mengirimkan “digitally signed acknowledgement” untuk memulai SSL encrypted session
  6. Data yang terenkripsi sudah dapat dikirim dan diterima oleh client dan server.

Penjelasan diatas disebut juga dengan SSL Handshake.

 

Dibawah ini adalah video yang mungkin dapat berguna untuk mempelajari SSL lebih lanjut

 

Sumber:

How SSL Works: https://www.symantec.com/page.jsp%3Fid%3Dhow-ssl-works

How SSL Works: https://www.thawte.com/resources/getting-started/how-ssl-works/

What is SSL: http://info.ssl.com/article.aspx?id=10241

 

Disclaimer:

Semua tulisan Saya adalah berdasarkan eksplorasi dan pemahaman Saya yang terbatas sejauh ini, Pembaca bebas memberikan masukan apabila ada yang kurang tepat. CMIIW abis lah pokoknya.