Pembaruan Akses Jaringan Pribadi: Memperkenalkan uji coba penghentian

Titouan Rigoudy
Titouan Rigoudy
Yifan Luo
Yifan Luo

Info Terbaru

  • 23 Maret 2023: Linimasa telah diperbarui, dan penghentian penggunaan tidak akan terjadi hingga Chrome 117.

  • 19 Januari 2023: Linimasa telah diperbarui, dan penghentian tidak akan terjadi hingga Chrome 114.

  • 12 Agustus 2022: Linimasa telah diperbarui, dan penghentian tidak akan terjadi hingga Chrome 109.

  • 10 Februari 2022: Artikel yang diperbarui dipublikasikan di Akses Jaringan Pribadi: memperkenalkan pra-penerbangan

  • 25 Agustus 2021: Memperbarui pengumuman linimasa dan memperkenalkan uji coba penghentian.

Chrome menghentikan penggunaan akses ke endpoint jaringan pribadi dari situs yang tidak aman sebagai bagian dari spesifikasi Akses Jaringan Pribadi. Tujuannya adalah untuk melindungi pengguna dari serangan pemalsuan permintaan lintas situs (CSRF) yang menarget router dan perangkat lain di jaringan pribadi. Serangan ini telah memengaruhi ratusan ribu pengguna, sehingga penyerang dapat mengalihkan mereka ke server berbahaya.

Chrome akan memperkenalkan perubahan berikut:

  • Memblokir permintaan ke jaringan pribadi dari situs publik yang tidak aman mulai Chrome 94.
  • Memperkenalkan uji coba penghentian penggunaan yang akan berakhir di Chrome
    1. Hal ini akan memungkinkan developer meminta perpanjangan waktu untuk origin yang dipilih, yang tidak akan terpengaruh selama uji coba penghentian.
  • Memperkenalkan kebijakan Chrome yang akan memungkinkan deployment Chrome terkelola untuk mengabaikan penghentian penggunaan secara permanen. Tersedia di Chrome 92.

Jika Anda memerlukan lebih banyak waktu untuk memitigasi dampak penghentian, daftarkan untuk uji coba penghentian.

Jika memiliki kontrol administratif atas pengguna, Anda dapat mengaktifkan kembali fitur tersebut menggunakan kebijakan Chrome.

Untuk mengurangi dampak pembatasan baru, gunakan salah satu strategi berikut:

Linimasa

  • November 2020: Meminta masukan tentang perubahan mendatang.
  • Maret 2021: Setelah meninjau masukan dan melakukan penjangkauan, perubahan mendatang akan diumumkan. Spesifikasi ini diganti namanya dari CORS-RFC1918 menjadi Akses Jaringan Pribadi.
  • April 2021: Chrome 90 diluncurkan ke versi Stabil, yang menampilkan peringatan penghentian penggunaan.
  • Juni 2021: Chrome 92 diluncurkan ke versi Beta, yang melarang permintaan jaringan pribadi dari konteks yang tidak aman. Setelah masukan dari developer yang meminta tambahan waktu untuk menyesuaikan, penghentian penggunaan akan dialihkan ke Chrome 93, yang akan disertai dengan Uji Coba Penghentian Penggunaan.
  • Juli 2021: Setelah masukan lebih lanjut dari developer, penghentian penggunaan dan uji coba yang menyertainya ditunda ke Chrome 94. Selain itu, situs pribadi tidak lagi terpengaruh oleh penghentian ini.
  • Agustus 2021: Chrome 94 diluncurkan ke Beta. Developer web dapat mulai mendaftar untuk uji coba penghentian penggunaan.
  • September 2021: Chrome 94 diluncurkan ke versi Stabil. Developer web harus telah mendaftar untuk uji coba penghentian penggunaan dan men-deploy token uji coba ke produksi.
  • Desember 2022: Survei uji coba Origin dikirim dan masukan diterima. Uji coba penghentian penggunaan diperluas ke Chrome 113.
  • Maret 2023: Uji coba penghentian penggunaan diperpanjang ke Chrome 116, dan ditetapkan untuk berakhir pada Chrome 117. Mekanisme alternatif berbasis izin sedang dalam pengembangan, yang menargetkan rilis awal di Chrome 114.
  • Mei 2023 (tentatif): Mekanisme berbasis izin diluncurkan di Chrome 114. Situs dapat menggunakannya untuk keluar dari uji coba penghentian penggunaan.
  • September 2023: Chrome 117 diluncurkan ke Stabil, mengakhiri uji coba penghentian penggunaan. Chrome memblokir semua permintaan jaringan pribadi dari konteks publik yang tidak aman.

Apa yang dimaksud dengan Akses Jaringan Pribadi

Akses Jaringan Pribadi (sebelumnya dikenal sebagai CORS-RFC1918) membatasi kemampuan situs untuk mengirim permintaan ke server di jaringan pribadi. API ini hanya mengizinkan permintaan tersebut dari konteks yang aman. Spesifikasi ini juga memperluas protokol Cross-Origin Resource Sharing (CORS) sehingga situs kini harus secara eksplisit meminta hibah dari server di jaringan pribadi sebelum diizinkan untuk mengirim permintaan arbitrer.

Permintaan jaringan pribadi adalah permintaan yang alamat IP server targetnya lebih bersifat pribadi daripada alamat IP tempat pemicu permintaan diambil. Misalnya, permintaan dari situs publik (https://example.com) ke situs pribadi (http://router.local), atau permintaan dari situs pribadi ke localhost.

Hubungan antara jaringan publik, pribadi, dan lokal di Akses Jaringan Pribadi (CORS-RFC1918).
Hubungan antara jaringan publik, pribadi, dan lokal di Akses Jaringan Pribadi (CORS-RFC1918).

Pelajari lebih lanjut di Feedback want: CORS untuk jaringan pribadi (RFC1918).

Pengertian uji coba penghentian penggunaan

Uji coba penghentian penggunaan (sebelumnya dikenal sebagai uji coba origin terbalik) adalah bentuk uji coba origin yang digunakan untuk memudahkan penghentian penggunaan fitur web. Uji coba penghentian penggunaan memungkinkan Chrome menghentikan penggunaan fitur web tertentu dan mencegah situs membentuk dependensi baru pada fitur tersebut, sekaligus memberi situs dependen saat ini waktu tambahan untuk bermigrasi dari fitur tersebut.

Selama uji coba penghentian penggunaan, fitur yang tidak digunakan lagi tidak tersedia untuk semua situs secara default. Developer yang masih perlu menggunakan fitur yang terpengaruh harus mendaftar ke uji coba penghentian penggunaan dan mendapatkan token untuk origin web yang ditentukan, lalu mengubah situs mereka untuk menayangkan token tersebut di header HTTP atau tag meta (kecuali dalam kasus ini). Jika situs menayangkan token valid yang cocok dengan asalnya, Chrome akan mengizinkan penggunaan fitur yang tidak digunakan lagi dalam jangka waktu terbatas.

Untuk informasi selengkapnya, lihat Memulai uji coba origin Chrome dan panduan developer web untuk uji coba origin untuk mendapatkan petunjuk.

Yang berubah di Chrome

Chrome 94

Mulai Chrome 94, konteks publik yang tidak aman (secara luas, situs yang tidak dikirimkan melalui HTTPS atau dari alamat IP pribadi) dilarang membuat permintaan ke jaringan pribadi. Hal ini sebelumnya direncanakan untuk Chrome 92, sehingga pesan penghentian penggunaan mungkin masih menyebutkan tonggak pencapaian sebelumnya.

Penghentian penggunaan ini disertai dengan uji coba penghentian penggunaan, yang memungkinkan developer web yang situsnya menggunakan fitur yang tidak digunakan lagi untuk terus menggunakannya hingga Chrome 116 dengan mendaftar untuk mendapatkan token. Lihat di bawah untuk mengetahui petunjuk cara mendaftar dan mengaktifkan uji coba di situs Anda.

Sepasang kebijakan Chrome dapat dimanfaatkan untuk menonaktifkan penghentian ini, baik sepenuhnya di origin tertentu, maupun di origin tertentu. Hal ini memungkinkan penginstalan Chrome terkelola, misalnya, yang ada di setelan perusahaan, untuk menghindari kerusakan.

Chrome 117

Uji coba penghentian penggunaan berakhir. Semua situs harus dimigrasikan dari fitur yang tidak digunakan lagi, atau kebijakan penggunanya yang dikonfigurasi untuk terus mengaktifkan fitur tersebut.

Langkah pertama untuk situs yang terpengaruh kemungkinan besar memerlukan waktu hingga perbaikan yang tepat dapat di-deploy: baik dengan mendaftar ke uji coba penghentian penggunaan, maupun dengan menggunakan kebijakan. Kemudian, tindakan yang direkomendasikan bervariasi bergantung pada kondisi setiap situs yang terpengaruh.

Mendaftar untuk uji coba penghentian

  1. Klik Register untuk Akses Jaringan Pribadi dari uji coba origin konteks tidak aman guna mendapatkan token uji coba untuk origin yang berpartisipasi.
  2. Tambahkan Origin-Trial: $token khusus origin ke header respons Anda. Header respons ini hanya perlu ditetapkan pada respons navigasi dan resource utama saat dokumen yang dihasilkan menggunakan fitur yang tidak digunakan lagi. Tidak ada gunanya (meskipun tidak berbahaya) untuk melampirkan header ini ke respons subresource.

Karena uji coba ini harus diaktifkan atau dinonaktifkan sebelum dokumen diizinkan untuk membuat permintaan apa pun, uji coba ini tidak dapat diaktifkan melalui tag <meta>. Tag tersebut hanya diuraikan dari isi respons setelah permintaan sub-resource mungkin telah diterbitkan. Hal ini menimbulkan tantangan bagi situs yang tidak mengontrol header respons, seperti situs statis github.io yang ditayangkan oleh pihak ketiga.

Untuk mengetahui detail selengkapnya, lihat Panduan developer web untuk uji coba origin.

Aktifkan kebijakan

Jika memiliki kontrol administratif atas pengguna, Anda dapat mengaktifkan kembali fitur yang tidak digunakan lagi menggunakan salah satu kebijakan berikut:

Untuk mengetahui detail selengkapnya tentang cara mengelola kebijakan untuk pengguna, lihat artikel pusat bantuan ini.

Mengakses localhost

Jika situs Anda perlu mengeluarkan permintaan ke localhost, Anda hanya perlu mengupgrade situs ke HTTPS.

Permintaan yang menargetkan http://localhost (atau http://127.*.*.*, http://[::1]) tidak diblokir oleh Konten Campuran, meskipun dikeluarkan dari konteks aman.

Perhatikan bahwa mesin WebKit dan browser yang didasarkan padanya (terutama, Safari) menyimpang dari spesifikasi Konten Campuran W3C di sini dan melarang permintaan ini sebagai Konten Campuran. Mereka juga tidak mengimplementasikan Akses Jaringan Pribadi, sehingga situs mungkin ingin mengalihkan klien yang menggunakan browser tersebut ke situs HTTP versi teks biasa, yang masih diizinkan oleh browser tersebut untuk membuat permintaan ke localhost.

Mengakses alamat IP pribadi

Jika situs Anda perlu mengeluarkan permintaan ke server target di alamat IP pribadi, mengupgrade situs inisiator ke HTTPS saja tidak akan berfungsi. Konten Campuran mencegah konteks aman membuat permintaan melalui HTTP teks biasa, sehingga situs yang baru diamankan masih tidak dapat membuat permintaan. Ada beberapa cara untuk mengatasi masalah ini:

  • Upgrade kedua ujungnya ke HTTPS.
  • Gunakan WebTransport untuk terhubung ke server target dengan aman.
  • Membalik hubungan penyematan.

Mengupgrade kedua ujung ke HTTPS

Solusi ini memerlukan kontrol atas resolusi DNS pengguna, seperti yang mungkin terjadi dalam konteks intranet, atau jika pengguna mendapatkan alamat server nama mereka dari server DHCP dalam kontrol Anda. Anda juga harus memiliki nama domain publik.

Masalah utama dalam menayangkan situs pribadi melalui HTTPS adalah bahwa otoritas sertifikat infrastruktur kunci publik (PKI CA) hanya menyediakan sertifikat TLS ke situs dengan nama domain publik. Untuk mengatasinya:

  1. Daftarkan nama domain publik (misalnya, intranet.example) dan publikasikan data DNS yang mengarahkan nama domain tersebut ke server publik pilihan Anda.
  2. Dapatkan sertifikat TLS untuk intranet.example.
  3. Di dalam jaringan pribadi Anda, konfigurasikan DNS untuk me-resolve intranet.example ke alamat IP pribadi server target.
  4. Konfigurasi server pribadi agar menggunakan sertifikat TLS untuk intranet.example. Hal ini memungkinkan pengguna Anda mengakses server pribadi di https://intranet.example.

Kemudian, Anda dapat mengupgrade situs yang memulai permintaan ke HTTPS dan terus membuat permintaan seperti sebelumnya.

Solusi ini siap untuk masa mendatang dan mengurangi kepercayaan yang Anda berikan ke jaringan, sehingga memperluas penggunaan enkripsi end-to-end dalam jaringan pribadi Anda.

WebTransport

Solusi ini tidak memerlukan kontrol atas resolusi DNS pengguna Anda. Hal ini memerlukan server target untuk menjalankan server WebTransport minimal (server HTTP/3 dengan beberapa modifikasi).

Anda dapat mengabaikan kurangnya sertifikat TLS yang valid dan ditandatangani oleh CA tepercaya dengan menggunakan WebTransport dan mekanisme penyematan sertifikat-nya. Hal ini memungkinkan pembuatan koneksi aman ke perangkat pribadi yang mungkin memiliki sertifikat yang ditandatangani sendiri, misalnya. Koneksi WebTransport memungkinkan transfer data dua arah, tetapi tidak mengambil permintaan. Anda dapat menggabungkan pendekatan ini dengan pekerja layanan untuk melakukan proxy permintaan HTTP secara transparan melalui koneksi, dari sudut pandang aplikasi web Anda. Di sisi server, lapisan terjemahan yang sesuai dapat mengonversi pesan WebTransport ke permintaan HTTP.

Kami menyadari bahwa ini merupakan pekerjaan yang cukup berat, tetapi seharusnya jauh lebih mudah daripada mem-build di atas WebRTC; harapan kami juga adalah beberapa jumlah investasi yang diperlukan akan diimplementasikan sebagai library yang dapat digunakan kembali. Kami juga yakin bahwa hal ini sangatlah penting mengingat fakta bahwa konteks yang tidak aman cenderung kehilangan akses ke semakin banyak fitur platform web seiring platform beralih untuk mendorong penggunaan HTTPS dengan cara yang lebih kuat dari waktu ke waktu. Terlepas dari Akses Jaringan Pribadi, ini mungkin adalah investasi yang bijaksana.

Kami memperkirakan WebTransport melalui HTTP/3 akan dikirimkan di Chrome 96 (telah memulai uji coba origin) dengan mitigasi untuk melindungi dari pembagian kunci dan praktik keamanan standar di bawah standar lainnya, termasuk:

  • Waktu habis masa berlaku maksimum yang singkat untuk sertifikat yang disematkan.
  • Mekanisme khusus browser untuk mencabut kunci tertentu yang telah menjadi target penyalahgunaan.

Kami tidak akan mengirimkan batasan konteks aman hingga setidaknya dua tonggak pencapaian setelah WebTransport diluncurkan sepenuhnya. Uji coba penghentian penggunaan akan diperpanjang jika diperlukan.

Menyematkan balik

Solusi ini tidak memerlukan kontrol administratif atas jaringan, dan dapat digunakan saat server target tidak cukup andal untuk menjalankan HTTPS.

Daripada mengambil sub-resource pribadi dari aplikasi web publik, kerangka aplikasi dapat ditayangkan dari server pribadi, yang kemudian mengambil semua sub-resource-nya (seperti skrip atau gambar) dari server publik, seperti CDN. Aplikasi web yang dihasilkan kemudian dapat membuat permintaan ke server pribadi, karena dianggap berasal dari origin yang sama. Server ini bahkan dapat membuat permintaan ke server lain dengan IP pribadi (tetapi bukan localhost), meskipun hal ini dapat berubah dalam jangka panjang.

Dengan hanya menghosting kerangka di server pribadi, Anda dapat mengupdate aplikasi web dengan mendorong resource baru ke server publik, seperti yang Anda lakukan untuk mengupdate aplikasi web publik. Di sisi lain, aplikasi web yang dihasilkan bukanlah konteks yang aman, sehingga tidak memiliki akses ke beberapa fitur web yang lebih canggih.

Rencana untuk masa mendatang

Membatasi permintaan jaringan pribadi ke konteks yang aman hanyalah langkah pertama dalam meluncurkan Akses Jaringan Pribadi. Chrome sedang berupaya menerapkan spesifikasi lainnya dalam beberapa bulan mendatang. Ikuti terus info terbarunya!

Membatasi akses localhost dari situs pribadi

Perubahan di Chrome 94 hanya memengaruhi situs publik yang mengakses alamat IP pribadi atau localhost. Spesifikasi Akses Jaringan Pribadi juga mengklasifikasikan permintaan dari situs pribadi ke localhost sebagai bermasalah. Chrome pada akhirnya juga akan menghentikan penggunaannya. Namun, hal ini menghadirkan serangkaian tantangan yang sedikit berbeda, karena banyak situs pribadi tidak memiliki nama domain, sehingga mempersulit penggunaan token uji coba penghentian.

Permintaan preflight CORS

Bagian kedua dari Akses Jaringan Pribadi adalah mengontrol permintaan jaringan pribadi yang dimulai dari konteks aman dengan permintaan preflight CORS. Idenya adalah meskipun permintaan dimulai dari konteks yang aman, server target diminta untuk memberikan pemberian eksplisit kepada inisiator. Permintaan hanya dikirim jika pemberian berhasil.

Singkatnya, permintaan pra-penerbangan CORS adalah permintaan OPTIONS HTTP yang membawa beberapa header Access-Control-Request-* yang menunjukkan sifat permintaan berikutnya. Server kemudian dapat memutuskan apakah akan memberikan akses terperinci atau tidak dengan merespons 200 OK dengan header Access-Control-Allow-*.

Temukan detail selengkapnya tentang hal ini di spesifikasi.

Membatasi pengambilan navigasi

Chrome menghentikan penggunaan dan pada akhirnya memblokir permintaan subresource ke jaringan pribadi. Hal ini tidak akan memengaruhi navigasi ke jaringan pribadi, yang juga dapat digunakan dalam serangan CSRF.

Spesifikasi Akses Jaringan Pribadi tidak membuat perbedaan antara dua jenis pengambilan, yang pada akhirnya akan tunduk pada pembatasan yang sama.

Foto sampul oleh Markus Spiske di Unsplash