Keamanan dengan HTTPS dan SSL

Secure Sockets Layer (SSL)—sekarang secara teknis dikenal sebagai Transport Layer Security (TLS)—adalah blok pembangun umum untuk komunikasi terenkripsi antara klien dan server. Ada kemungkinan bahwa aplikasi menggunakan SSL dengan tidak benar sehingga benda berbahaya mungkin mencegat data aplikasi melalui jaringan. Untuk membantu Anda memastikan bahwa hal ini tidak terjadi untuk aplikasi Anda, artikel ini menyoroti perangkap umum saat menggunakan protokol jaringan yang aman dan mengatasi beberapa kekhawatiran yang lebih besar tentang penggunaan Public-Key Infrastructure (PKI).

Konsep

Dalam skenario penggunaan SSL umum, server dikonfigurasi dengan sertifikat yang berisi kunci publik serta kunci privat yang cocok. Sebagai bagian dari persetujuan antara klien dan server SSL, server membuktikan kepemilikan kunci privat dengan menandatangani sertifikat dengan kriptografi kunci publik.

Akan tetapi, siapa pun bisa menghasilkan sertifikat dan kunci privat sendiri, sehingga persetujuan yang sederhana tidak membuktikan apa pun tentang server selain bahwa server mengetahui kunci privat yang cocok dengan kunci publik dari sertifikat. Salah satu cara untuk memecahkan masalah ini adalah agar klien memiliki kumpulan yang terdiri dari satu atau beberapa sertifikat yang dipercaya. Jika sertifikat tidak ada dalam set tersebut, server tidak bisa dipercaya.

Ada sejumlah kelemahan dari pendekatan sederhana ini. Server harus bisa meningkatkan versi ke kunci yang lebih kuat dari waktu ke waktu ("rotasi kunci"), yang menggantikan kunci publik dalam sertifikat dengan yang baru. Sayangnya, sekarang aplikasi klien harus diperbarui karena perubahan konfigurasi server. Hal ini akan bermasalah jika server tidak di bawah kontrol developer aplikasi, misalnya jika itu adalah layanan web pihak ketiga. Pendekatan ini juga memiliki masalah jika aplikasi harus berkomunikasi ke server bebas seperti browser web atau aplikasi email.

Untuk mengatasi kekurangan ini, server biasanya dikonfigurasi dengan sertifikat dari penerbit terkenal yang disebut Certificate Authorities (CA). Platform host biasanya berisi daftar CA terkenal yang dipercaya. Hingga Android 4.2 (Jelly Bean), Android saat ini berisi lebih dari 100 CA yang diperbarui dalam setiap rilis. Seperti halnya pada server, CA memiliki sertifikat dan kunci privat. Ketika menerbitkan sertifikat untuk server, CA akan menandatangani sertifikat server menggunakan kunci privatnya. Klien kemudian bisa melakukan verifikasi bahwa server memiliki sertifikat yang diterbitkan oleh CA yang dikenal platform.

Akan tetapi, meskipun memecahkan beberapa masalah, penggunaan CA memunculkan masalah lain. Karena CA menerbitkan sertifikat untuk banyak server, Anda memerlukan beberapa cara untuk memastikan bahwa Anda berkomunikasi ke server yang diinginkan. Untuk mengatasi hal ini, sertifikat yang dikeluarkan oleh CA mengenali server dengan nama spesifik seperti gmail.com atau kumpulan karakter pengganti dari host seperti *.google.com.

Contoh berikut akan membuat konsep ini sedikit lebih konkret. Dalam cuplikan di bawah dari baris perintah, perintah s_client dari alat openssl melihat informasi sertifikat server Wikipedia. Ini menetapkan porta 443 karena itu adalah default untuk HTTPS. Perintah mengirimkan keluaran dariopenssl s_client ke openssl x509, yang memformat informasi tentang sertifikat yang sesuai dengan standar X.509. Secara khusus, perintah meminta subjek, yang berisi informasi nama server, dan penerbit, yang mengidentifikasi CA.

$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA

Anda bisa melihat bahwa sertifikat yang diterbitkan untuk server cocok dengan *.wikipedia.org oleh RapidSSL CA.

Contoh HTTPS

Anggap saja Anda memiliki sebuah server web dengan sertifikat yang diterbitkan oleh CA terkenal, Anda bisa membuat permintaan aman dengan kode semudah ini:

URL url = new URL("https://wikipedia.org");
URLConnection urlConnection = url.openConnection();
InputStream in = urlConnection.getInputStream();
copyInputStreamToOutputStream(in, System.out);

Ya, benar-benar bisa semudah itu. Jika Anda ingin menyesuaikan permintaan HTTP, Anda bisa mentransmisikan ke sebuah HttpURLConnection. Dokumentasi Android untuk HttpURLConnection memiliki contoh lebih jauh tentang cara menangani permintaan dan header respons, mengeposkan materi, mengelola cookie, menggunakan proxy, caching respons, dan sebagainya. Namun untuk detail memverifikasi sertifikat dan hostname, kerangka kerja Android menanganinya untuk Anda melalui API ini. Ini adalah tempat Anda ingin berada jika keadaan memungkinkan. Di bawah ini adalah beberapa pertimbangan lainnya.

Masalah Umum dalam Memverifikasi Sertifikat Server

Anggaplah sebagai ganti menerima materi dari getInputStream(), tetapi melontarkan pengecualian:

javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
        at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:374)
        at libcore.net.http.HttpConnection.setupSecureSocket(HttpConnection.java:209)
        at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.makeSslConnection(HttpsURLConnectionImpl.java:478)
        at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.connect(HttpsURLConnectionImpl.java:433)
        at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:290)
        at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:240)
        at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:282)
        at libcore.net.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:177)
        at libcore.net.http.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:271)

Hal ini bisa terjadi karena sejumlah alasan, antara lain:

  1. CA yang mengeluarkan sertifikat server tak dikenal
  2. Sertifikat server tidak ditandatangani oleh CA, namun ditandatangani sendiri
  3. Konfigurasi server kehilangan CA perantara

Bagian berikut membahas cara mengatasi masalah ini sambil menjaga koneksi Anda ke server tetap aman.

Otoritas sertifikat tak dikenal

Dalam kasus ini, SSLHandshakeException terjadi karena Anda memiliki CA yang tidak dipercaya oleh sistem. Bisa jadi karena Anda memiliki sertifikat dari CA baru yang belum dipercaya oleh Android atau aplikasi Anda berjalan pada versi lama tanpa CA. Sering kali CA tak dikenal karena bukan CA publik, namun CA privat yang dikeluarkan oleh organisasi seperti pemerintah, perusahaan, atau lembaga pendidikan untuk mereka gunakan sendiri.

Untungnya, Anda bisa mengajari HttpsURLConnection untuk mempercayai kumpulan CA tertentu. Prosedurnya bisa sedikit rumit, di bawah ini adalah contoh yang mengambil CA dari InputStream, menggunakannya untuk membuat KeyStore, yang kemudian digunakan untuk membuat dan melakukan inisialiasi TrustManager. Sebuah TrustManager adalah yang digunakan sistem untuk memvalidasi sertifikat dari server dan—dengan membuat satu dari KeyStore dengan satu atau beberapa CA—itu akan menjadi satu-satunya CA yang dipercaya oleh TrustManager.

Diberikan TrustManager baru, contoh melakukan inisialiasi SSLContext baru yang menyediakan SSLSocketFactory yang bisa Anda gunakan untuk mengganti SSLSocketFactory default dari HttpsURLConnection. Dengan cara ini koneksi akan menggunakan CA untuk validasi sertifikat.

Inilah contoh menggunakan penuh CA organisasi dari University of Washington:

// Load CAs from an InputStream
// (could be from a resource or ByteArrayInputStream or ...)
CertificateFactory cf = CertificateFactory.getInstance("X.509");
// From https://www.washington.edu/itconnect/security/ca/load-der.crt
InputStream caInput = new BufferedInputStream(new FileInputStream("load-der.crt"));
Certificate ca;
try {
    ca = cf.generateCertificate(caInput);
    System.out.println("ca=" + ((X509Certificate) ca).getSubjectDN());
} finally {
    caInput.close();
}

// Create a KeyStore containing our trusted CAs
String keyStoreType = KeyStore.getDefaultType();
KeyStore keyStore = KeyStore.getInstance(keyStoreType);
keyStore.load(null, null);
keyStore.setCertificateEntry("ca", ca);

// Create a TrustManager that trusts the CAs in our KeyStore
String tmfAlgorithm = TrustManagerFactory.getDefaultAlgorithm();
TrustManagerFactory tmf = TrustManagerFactory.getInstance(tmfAlgorithm);
tmf.init(keyStore);

// Create an SSLContext that uses our TrustManager
SSLContext context = SSLContext.getInstance("TLS");
context.init(null, tmf.getTrustManagers(), null);

// Tell the URLConnection to use a SocketFactory from our SSLContext
URL url = new URL("https://certs.cac.washington.edu/CAtest/");
HttpsURLConnection urlConnection =
    (HttpsURLConnection)url.openConnection();
urlConnection.setSSLSocketFactory(context.getSocketFactory());
InputStream in = urlConnection.getInputStream();
copyInputStreamToOutputStream(in, System.out);

Dengan TrustManager khusus yang mengetahui CA Anda, sistem bisa memvalidasi bahwa sertifikat server Anda datang dari penerbit tepercaya.

Perhatian: Banyak situs web menjelaskan tentang sebuah solusi alternatif jelek yang memasang TrustManager namun tidak melakukan apa-apa. Jika Anda melakukannya, Anda mungkin tidak mengenkripsi komunikasi Anda, karena siapa pun bisa menyerang pengguna Anda di hotspot Wi-Fi publik dengan menggunakan trik DNS untuk mengirimkan lalu lintas ke pengguna melalui proxy mereka sendiri yang berpura-pura menjadi server Anda. Penyerang kemudian bisa merekam sandi dan data pribadi lainnya. Ini bekerja karena penyerang bisa menghasilkan sertifikat dan—tanpa sebuah TrustManager yang benar-benar melakukan validasi bahwa sertifikat tersebut berasal dari sumber terpercaya—aplikasi Anda bisa saja berkomunikasi dengan siapa pun. Jadi jangan lakukan hal ini, bahkan untuk sementara sekalipun. Anda bisa membuat aplikasi untuk percaya pada penerbit sertifikat server, jadi lakukan saja hal ini.

Sertifikat server ditandatangani-sendiri

Kasus kedua dari SSLHandshakeException adalah karena sertifikat yang ditandatangani-sendiri, yang berarti server berperilaku sebagai CA-nya sendiri. Hal ini serupa dengan otoritas sertifikat tak dikenal, sehingga Anda bisa menggunakan pendekatan yang sama dengan bagian sebelumnya.

Anda bisa membuat TrustManager Anda sendiri, saat ini dengan mempercayai sertifikat server secara langsung. Ini memiliki semua kekurangan yang sebelumnya telah dibahas karena mengikat aplikasi secara langsung ke sertifikat, tapi bisa dilakukan dengan aman. Akan tetapi, Anda harus berhati-hati untuk memastikan sertifikat yang ditandatangani-sendiri memiliki kunci yang cukup kuat. Sampai 2012, 2048-bit RSA signature dengan eksponen 65537 yang berakhir tahunan bisa diterima. Ketika merotasi kunci, Anda sebaiknya memeriksa saran dari otoritas (seperti NIST) tentang apa yang bisa diterima.

Kehilangan otoritas sertifikat perantara

Kasus ketiga SSLHandshakeException terjadi karena CA perantara yang hilang. Kebanyakan CA publik tidak menandatangani sertifikat server secara langsung. Sebagai gantinya, mereka menggunakan Sertifikat CA utama, disebut sebagai CA akar, untuk menandatangani CA perantara. Mereka melakukan ini sehingga CA akar bisa disimpan secara offline untuk mengurangi risiko bahaya. Akan tetapi, sistem operasi seperti Android biasanya hanya mempercayai CA akar secara langsung, yang menyisakan sedikit celah kepercayaan antara sertifikat server—yang ditandatangani CA perantara—dan verifier sertifikat, yang mengetahui CA akar. Untuk mengatasi ini, server tidak mengirimkan klien hanya sertifikatnya selama handshake SSL, namun rantai sertifikat dari CA server melalui perantara diperlukan untuk mencapai CA akar terpercaya.

Untuk melihat bagaimana ini terlihat dalam praktik, berikut rantai sertifikat mail.google.com seperti terlihat oleh openssl perintah s_client:

$ openssl s_client -connect mail.google.com:443
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---

Ini memperlihatkan bahwa server akan mengirimkan sertifikat untuk mail.google.com yang diterbitkan oleh Thawte SGC CA, yang merupakan CA perantara dan sertifikat kedua untuk Thawte SGC CA diterbitkan oleh Verisign CA, yang merupakan CA utama yang dipercaya oleh Android.

Akan tetapi, tidak jarang mengonfigurasi server dengan tidak menyertakan CA perantara yang diperlukan. Misalnya, inilah server yang bisa menyebabkan kesalahan dalam Browser Android dan pengecualian dalam aplikasi Android:

$ openssl s_client -connect egov.uscis.gov:443
---
Certificate chain
 0 s:/C=US/ST=District Of Columbia/L=Washington/O=U.S. Department of Homeland Security/OU=United States Citizenship and Immigration Services/OU=Terms of use at www.verisign.com/rpa (c)05/CN=egov.uscis.gov
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3
---

Yang menarik untuk dicatat di sini adalah bahwa mengunjungi server ini di sebagian besar Browser desktop tidak menyebabkan kesalahan seperti yang ditimbulkan oleh CA yang tak dikenal sama sekali atau sertifikat server yang ditandatangani-sendiri. Hal ini karena kebanyakan cache Browser desktop lama kelamaan akan mempercayai CA perantara. Setelah mengunjungi dan mempelajari CA perantara dari satu situs, Browser tidak perlu memasukkan CA perantara dalam rantai sertifikat di waktu berikutnya.

Beberapa situs melakukan ini dengan sengaja untuk server web sekunder yang digunakan untuk menyediakan sumber daya. Misalnya, mungkin laman HTML utama mereka disajikan oleh server dengan rantai sertifikat penuh, namun menggunakan server untuk sumber daya seperti gambar, CSS, atau JavaScript tanpa CA, mungkin untuk menghemat bandwidth. Sayangnya, terkadang server ini memberikan layanan web yang Anda coba panggil dari aplikasi Android, yang berefek negatif.

Ada dua pendekatan untuk memecahkan masalah ini:

  • Mengonfigurasi server untuk menyertakan CA perantara dalam rantai Server. Sebagian besar CA memberikan dokumentasi tentang cara melakukan hal ini untuk semua server web umum. Ini adalah satu-satunya pendekatan jika Anda menginginkan situs bekerja dengan Browser Android default setidaknya melalui Android 4.2.
  • Atau, perlakukan CA perantara seperti CA tak dikenal lainnya, dan membuat TrustManager untuk memercayai secara langsung, seperti yang dilakukan di dua bagian sebelumnya.

Masalah Umum dengan Verifikasi Hostname

Seperti yang disebutkan di awal artikel ini, ada dua bagian kunci untuk melakukan verifikasi koneksi SSL. Yang pertama adalah melakukan verifikasi sertifikat tersebut dari sumber yang tepercaya, yang merupakan fokus dari bagian sebelumnya. Yang menjadi fokus bagian ini adalah bagian kedua: memastikan server yang Anda hubungi menyajikan sertifikat yang benar. Bila tidak, Anda biasanya akan melihat kesalahan seperti ini:

java.io.IOException: Hostname 'example.com' was not verified
        at libcore.net.http.HttpConnection.verifySecureSocketHostname(HttpConnection.java:223)
        at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.connect(HttpsURLConnectionImpl.java:446)
        at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:290)
        at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:240)
        at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:282)
        at libcore.net.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:177)
        at libcore.net.http.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:271)

Salah satu alasan kenapa ini bisa terjadi adalah karena kesalahan konfigurasi server. Server dikonfigurasi dengan sertifikat yang tidak memiliki bidang subjek atau bidang nama alternatif subjek yang cocok dengan server yang sedang coba Anda hubungi. Dimungkinkan untuk memiliki satu sertifikat yang digunakan dengan banyak server yang berbeda. Misalnya, dengan melihat sertifikat google.com dengan openssl s_client -connect google.com:443 | openssl x509 -text Anda bisa melihat subjek yang mendukung *.google.com tetapi juga nama alternatif subjek untuk *.youtube.com, *.android.com, dan lainnya. Kesalahan ini terjadi hanya bila nama server yang ingin Anda hubungi tidak terdaftar oleh sertifikat sebagai bisa diterima.

Sayangnya ini bisa terjadi karena alasan lain juga: hosting virtual. Ketika berbagi server untuk lebih dari satu hostname dengan HTTP, server web bisa membedakannya dari permintaan HTTP/1.1 yang menargetkan hostname yang dicari klien. Sayangnya ini menjadi rumit dengan HTTPS, karena server harus mengetahui mana sertifikat yang dikembalikan sebelum melihat permintaan HTTP. Untuk mengatasinya, versi SSL yang lebih baru, khususnya TLSv.1.0 dan yang lebih baru, mendukung Server Name Indication (SNI), yang memungkinkan klien SSL untuk menetapkan hostname yang dimaksudkan ke server sehingga sertifikat yang tepat bisa dikembalikan.

Untungnya, HttpsURLConnection mendukung SNI sejak Android 2.3. Salah satu solusi jika Anda perlu untuk mendukung Android 2.2 (dan yang lebih lama) adalah dengan mempersiapkan sebuah virtual host alternatif pada porta unik sehingga jelas sertifikat server mana yang dikembalikan.

Alternatif yang lebih ekstrem adalah mengganti HostnameVerifier dengan yang tidak menggunakan hostname dari virtual host Anda, tapi yang dikembalikan oleh server secara default.

Perhatian: Mengganti HostnameVerifier bisa sangat berbahaya jika virtual host lain tidak di bawah kendali Anda, karena serangan man-in-the-middle bisa mengarahkan lalu lintas ke server lain tanpa sepengetahuan Anda.

Jika Anda tetap yakin akan mengganti verifikasi hostname, inilah contoh yang menggantikan verifier untuk URLConnection tunggal dengan yang masih memverifikasi bahwa hostname tersebut setidaknya sesuai harapan aplikasi:

// Create an HostnameVerifier that hardwires the expected hostname.
// Note that is different than the URL's hostname:
// example.com versus example.org
HostnameVerifier hostnameVerifier = new HostnameVerifier() {
    @Override
    public boolean verify(String hostname, SSLSession session) {
        HostnameVerifier hv =
            HttpsURLConnection.getDefaultHostnameVerifier();
        return hv.verify("example.com", session);
    }
};

// Tell the URLConnection to use our HostnameVerifier
URL url = new URL("https://example.org/");
HttpsURLConnection urlConnection =
    (HttpsURLConnection)url.openConnection();
urlConnection.setHostnameVerifier(hostnameVerifier);
InputStream in = urlConnection.getInputStream();
copyInputStreamToOutputStream(in, System.out);

Namun ingat, jika Anda memutuskan mengganti verifikasi hostname, terutama karena hosting virtual, tetap sangat berbahaya jika host virtual lain tidak di bawah kendali Anda dan Anda sebaiknya menemukan pengaturan hosting alternatif sehingga bisa terhindar dari masalah ini.

Peringatan Tentang Penggunaan SSLSocket Secara Langsung

Sejauh ini, contoh berfokus pada HTTPS menggunakan HttpsURLConnection. Terkadang aplikasi perlu menggunakan SSL terpisah dari HTTP. Misalnya, sebuah aplikasi email mungkin menggunakan varian SSL dari SMTP, POP3, atau IMAP. Dalam kasus tersebut, aplikasi ingin menggunakan SSLSocket secara langsung, seperti yang dilakukan HttpsURLConnection secara internal.

Teknik yang dijelaskan sejauh ini untuk menangani masalah verifikasi sertifikat juga berlaku untuk SSLSocket. Bahkan, saat menggunakan TrustManager khusus, apa yang akan diteruskan ke HttpsURLConnection adalah sebuah SSLSocketFactory. Jadi, jika Anda perlu menggunakan TrustManager khusus dengan SSLSocket, ikuti langkah-langkah yang sama dan menggunakan SSLSocketFactory tersebut untuk membuat SSLSocket Anda.

Perhatian: SSLSocket tidak melakukan verifikasi hostname. Terserah aplikasi Anda untuk melakukan verifikasi hostname sendiri, lebih baik memanggil getDefaultHostnameVerifier() dengan hostname yang diinginkan. Selanjutnya berhati-hatilah bahwa HostnameVerifier.verify() tidak melontarkan pengecualian pada kesalahan melainkan mengembalikan hasil boolean yang harus diperiksa secara eksplisit.

Inilah contoh yang menampilkan bagaimana Anda bisa melakukannya. Contoh ini menunjukkan bahwa saat menghubungkan ke gmail.com porta 443 tanpa dukungan SNI, Anda akan menerima sertifikat untuk mail.google.com. Hal ini memang sudah diperkirakan, jadi periksa untuk memastikan bahwa sertifikat tersebut memang untuk mail.google.com:

// Open SSLSocket directly to gmail.com
SocketFactory sf = SSLSocketFactory.getDefault();
SSLSocket socket = (SSLSocket) sf.createSocket("gmail.com", 443);
HostnameVerifier hv = HttpsURLConnection.getDefaultHostnameVerifier();
SSLSession s = socket.getSession();

// Verify that the certicate hostname is for mail.google.com
// This is due to lack of SNI support in the current SSLSocket.
if (!hv.verify("mail.google.com", s)) {
    throw new SSLHandshakeException("Expected mail.google.com, "
                                    "found " + s.getPeerPrincipal());
}

// At this point SSLSocket performed certificate verificaiton and
// we have performed hostname verification, so it is safe to proceed.

// ... use socket ...
socket.close();

Daftar hitam

SSL sangat bergantung pada CA untuk menerbitkan sertifikat hanya bagi pemilik server dan domain yang sudah diverifikasi dengan benar. Dalam kasus yang jarang terjadi, CA diperdaya atau, dalam kasus Comodo atau DigiNotar, dilanggar, sehingga sertifikat untuk hostname diterbitkan untuk orang lain selain dari pemilik server atau domain.

Untuk mengurangi risiko ini, Android memiliki kemampuan untuk membuat daftar hitam sertifikat tertentu atau bahkan seluruh CA. Meskipun daftar ini secara historis dibangun ke dalam sistem operasi, mulai Android 4.2, daftar ini bisa diperbarui dari jarak jauh untuk menangani keadaan berbahaya masa mendatang.

Pinning

Aplikasi bisa melindungi dirinya lebih jauh dari sertifikat palsu yang dikeluarkan dari teknik yang dikenal sebagai pinning. Ini pada dasarnya menggunakan contoh yang diberikan dalam kasus CA tak dikenal di atas untuk membatasi CA yang dipercaya aplikasi ke kelompok kecil yang dikenal untuk digunakan oleh server aplikasi. Hal ini untuk mencegah salah satu CA berbahaya dari 100+ CA lainnya dalam sistem yang bisa mengakibatkan penerobosan saluran aman aplikasi.

Sertifikat Klien

Artikel ini berfokus pada pengguna SSL untuk mengamankan komunikasi dengan server. SSL juga mendukung konsep sertifikat klien yang memungkinkan server untuk memvalidasi identitas klien. Meskipun di luar cakupan artikel ini, teknik yang terlibat mirip dengan penetapan TrustManager khusus. Lihat pembahasan mengenai pembuatan KeyManager khusus dalam dokumentasi untuk HttpsURLConnection.

Nogotofail: Alat Pengujian Keamanan Lalu Lintas Jaringan

Nogotofail adalah alat yang memberi Anda kemudahan untuk mengkonfirmasi bahwa aplikasi Anda aman terhadap kerentanan dan kesalahan konfigurasi TLS/SSL yang dikenal. Inilah alat yang otomatis, kuat, dan skalabel untuk pengujian masalah keamanan jaringan pada perangkat apa pun yang bisa dilalui lalu lintas jaringan.

Nogotofail bermanfaat untuk tiga kasus penggunaan utama:

  • Menemukan bug dan kerentanan.
  • Memverifikasi perbaikan dan memperhatikan regresi.
  • Memahami lalu lintas apa yang akan dihasilkan aplikasi dan perangkat.

Nogotofail berfungsi untuk Android, iOS, Linux, Windows, Chrome OS, OSX, bahkan semua perangkat yang Anda gunakan untuk terhubung ke Internet. Terdapat klien yang mudah digunakan untuk mengonfigurasi setelan dan mendapatkan notifikasi di Android dan Linux, serta mesin serangan yang bisa diterapkan sebagai router, server VPN, atau proxy.

Anda bisa mengakses alat ini di proyek sumber terbuka Nogotofail.