Baru-baru ini muncul berita bahawa Apple, Cloudflare, Fastly, dan Mozilla telah berkolaborasi untuk meningkatkan enkripsi mekanisme Identifikasi Nama Server HTTPS di Hackathon IETF 102 seperti yang ditunjukkan oleh tweet dari Nick Sullivan Cloudflare. Tweet itu mengucapkan tahniah kepada pasukan campuran dari empat syarikat gergasi teknologi dengan mengatakan 'Kerja yang luar biasa' dan berkongsi di sana di bawah pautan ke pelayan yang berfungsi di esni.examp1e.net dan cloudflare-esni.com .
Kerja hebat di hackathon IETF 102 oleh pasukan SNI yang disulitkan yang terdiri daripada orang-orang dari @Cloudflare @ cepat @mozilla dan @epal . Kini terdapat pelaksanaan di BoringSSL, NSS dan picotls.
Pelayan berfungsi ditayangkan di https://t.co/sLI9xLRjlK dan https://t.co/AoC2SIlJ7N .
- Nick Sullivan (@grittygrease) 15 Julai 2018
IETF Hackathon adalah platform yang mengundang pemaju muda dan peminat teknologi untuk bergabung dalam merangka penyelesaian untuk masalah berkaitan teknologi yang dihadapi oleh pengguna biasa hari ini. Acara bebas untuk disertai, terbuka untuk semua, dan mereka mendorong kerja berpasukan berbanding persaingan. Hackathon IETF tahun ini diadakan di Montreal pada 14ikadan 15ikabulan Julai. Nampaknya, pencapaian paling menonjol daripadanya adalah enkripsi Indikasi Nama Pelayan Transport Layer Security (TLS) (SNI), masalah yang telah melanda para pembangun selama dekad yang lalu, salah satu yang dianggotai oleh Apple, Cloudflare, Fastly , dan Mozilla kini telah mengemukakan penyelesaian untuk.
Acara Hackathon IETF. IETF
Terdapat perubahan global yang jelas dari Hyper Text Transfer Protocol (HTTP) ke Transport Layer Security Server Name Indication Hyper Text Transfer Protocol Secure (TLS SNI HTTPS) dalam satu dekad setengah terakhir. The masalah yang tidak dapat mengoptimumkan sistem HTLPS TLS SNI adalah kemampuan penggodam untuk menggunakan SNI berbanding tujuannya untuk memadankan pemindahan data untuk penyahsulitan kemudian.
Sebelum pengembangan SNI, sukar untuk membuat sambungan selamat ke beberapa pelayan maya menggunakan jabat tangan pelanggan pertama yang sama. Apabila satu alamat IP berinteraksi dengan satu pelayan, kedua-duanya bertukar 'hellos,' pelayan menghantar sijilnya, komputer menghantar kunci pelanggannya, kedua-duanya bertukar perintah 'ChangeCipherSpec' dan kemudian interaksi itu selesai ketika sambungan terjalin. Ini mungkin terdengar mudah seperti yang telah dikatakan tetapi prosesnya melibatkan banyak pertukaran dan respons yang dengan mudah berjaya menjadi agak bermasalah kerana jumlah pelayan yang dikomunikasikan meningkat. Sekiranya semua laman web menggunakan sijil yang sama, maka ini tidak banyak masalah, tetapi sayangnya jarang berlaku. Ketika beberapa laman web menghantar pelbagai sijil berulang-ulang, sukar bagi pelayan untuk menentukan sijil mana yang dicari komputer dan di web pertukaran yang kompleks, menjadi sukar untuk mengenal pasti siapa yang mengirim apa dan kapan, dengan itu menghentikan keseluruhan aktiviti dengan mesej amaran sama sekali.
TLS SNI kemudian diperkenalkan pada bulan Jun 2003 melalui sidang kemuncak IETF dan tujuannya, dalam arti tertentu, adalah membuat tanda nama untuk komputer dan perkhidmatan yang terlibat dalam web pertukaran. Ini menjadikan proses pertukaran pelanggan-pelayan menjadi lebih lurus ke hadapan kerana pelayan dapat memberikan sijil tepat yang diperlukan dan kedua-duanya dapat membuat pertukaran perbualan mereka sendiri tanpa bingung mengenai siapa yang mengatakan apa. Ia seperti mempunyai nama kenalan untuk berbual dan tidak keliru dari mana asalnya mesej itu, dan juga dapat membalas setiap pertanyaan dengan tepat, memberikan dokumen yang tepat kepada komputer mana pun yang memerlukannya. Definisi SNI inilah yang mendorong masalah terbesar dengan kaedah mengoptimumkan proses pertukaran ini.
Perjuangan yang dihadapi oleh banyak syarikat ketika beralih ke HTTPS adalah penyesuaian banyak sijil ke format SNI dengan alamat IP individu untuk melakukan permintaan untuk setiap sijil. Apa yang TLS lakukan untuk mereka adalah menjadikannya lebih mudah untuk menghasilkan sijil untuk menanggapi permintaan tersebut dan apa yang dilakukan oleh SNI lebih jauh adalah menghilangkan keperluan untuk alamat IP sijil khusus dengan melemparkan sistem pengenalan keseluruhan ke seluruh rangkaian internet. Apa yang terjadi dengan peningkatan abad ini adalah kenyataan bahawa ia membolehkan penggodam menggunakan 'nama kenalan' yang sudah ada untuk memantau dan membayang-bayang pemindahan data dan mengekstrak maklumat yang mereka perlukan untuk mendekripsi di kemudian hari.
Walaupun TLS memungkinkan data dikirim bolak-balik dalam saluran yang dienkripsi, dengan SNI memastikan bahawa ia mencapai tujuan yang betul, yang terakhir ini juga menyediakan cara bagi penggodam untuk memantau aktiviti dalam talian dan memadankannya dengan sumbernya dengan mengikuti permintaan DNS, alamat IP , dan aliran data. Walaupun dasar pengekodan SNI yang lebih ketat telah dilaksanakan dengan menyebarkan maklumat DNS melalui saluran TLS juga, masih ada tetingkap kecil bagi penggodam untuk dapat menggunakannya sebagai alat pengenalan untuk mengikuti sekeping maklumat yang ingin mereka ekstrak dan mengasingkannya untuk penyahsulitan. Pelayan yang rumit yang berurusan dengan trafik data enkripsi TLS yang lebih besar menggunakan SNI teks biasa untuk menghantar komunikasi di pelayan mereka dan inilah yang memudahkan para penggodam untuk mengenal pasti saluran dan aliran maklumat yang ingin mereka ikuti. Setelah penggodam dapat mengekstrak maklumat SNI dari data yang diminati, dia dapat mengatur ulangan perintah palsu dalam sambungan TLS yang berasingan dengan pelayan, menghantar maklumat SNI dicuri dan mengambil maklumat yang dikaitkan dengannya. Terdapat beberapa percubaan untuk menyelesaikan masalah SNI ini pada masa lalu tetapi kebanyakannya bertentangan dengan prinsip kesederhanaan yang dijalankan oleh SNI untuk menjadikannya kaedah pengenalan yang mudah untuk pelayan.
Kembali ke puncak yang pertama kali berusaha untuk mewujudkan kaedah ini, para peserta dari empat syarikat gergasi teknologi telah kembali ke persidangan di Montreal untuk mengembangkan penyulitan untuk TLS SNI kerana walaupun kecekapan yang lebih besar dalam sistem bersebelahan HTTPS, keselamatan masih menjadi perhatian sama seperti sebelumnya.
Untuk menyembunyikan SNI di TLS, 'Perkhidmatan Tersembunyi' mesti disimpan di bawah pertunjukan 'Fronting Service' yang mungkin dilihat oleh penggodam. Tanpa dapat melihat secara langsung perkhidmatan tersembunyi, penggodam akan disesatkan oleh penyamaran depan yang disembunyikannya dalam teks biasa tanpa dapat mengenal pasti parameter perkhidmatan rahsia yang digunakan untuk menyampaikan data yang dienkripsi. Semasa pemerhati mengikuti jejak perkhidmatan fronting, data akan dikeluarkan dari saluran yang diperhatikan kerana diarahkan ke perkhidmatan tersembunyi yang dimaksudkan dan pada masa itu penggodam akan kehilangan jejaknya. Oleh kerana pelayan juga akan terdedah kepada perkhidmatan depan, kerana data menuju ke sana, isyarat SNI selari kedua akan dihantar ke perkhidmatan depan untuk mengarahkan data ke perkhidmatan tersembunyi dan dalam proses perubahan arah ini, penggodam akan hilang di web pelayan. Mekanisme tiket berganda ini terus dikembangkan menjadi tiket gabungan di bawah SNI yang sama. Oleh kerana satu data dihantar ke pelayan, data menghasilkan pengarah semula SNI yang bekerjasama dan kedua-duanya bekerja bersama-sama untuk mendapatkan data yang dienkripsi TLS ke tempat yang diperlukan. Tanpa dapat memecahkan perkhidmatan frontal secara rawak yang merangkumi kedua trek SNI, penggodam tidak akan dapat mengikuti jejak data tetapi pelayan masih dapat menghubungkan kedua-duanya dan mendekripsi perkhidmatan tersembunyi sebagai lokasi utama data. Ini membolehkan pelayan terus menggunakan SNI untuk mengoptimumkan pemindahan data mereka dalam enkripsi TLS sambil memastikan bahawa penggodam tidak dapat memanfaatkan mekanisme SNI.
![[FIX] Hulu Kami Mengalami Kesalahan Semasa Beralih Profil](https://jf-balio.pt/img/how-tos/80/hulu-we-encountered-an-error-when-switching-profiles.png)
