Panduan HTTPS untuk Engineer Biasa

 (devonperoutky.super.site)
6 poin oleh GN⁺ 2024-05-27 | 1 komentar | Bagikan ke WhatsApp
  • Komunikasi internet memiliki struktur di mana paket diproses oleh beberapa lapisan yang berbeda, dan berkat protokol berlapis, developer tidak perlu menangani langsung detail implementasi transport, routing, maupun keamanan
  • Permintaan HTTP mengikuti alur bertahap yang dimulai dari pembuatan pesan oleh browser, lalu DNS lookup, TCP 3-way handshake, melewati router, hingga respons server
  • HTTP dasar mengirim header dan body dalam bentuk plaintext, sehingga rentan terhadap penyadapan dan penyamaran server; untuk menutup keterbatasan ini, ditambahkan lapisan keamanan
  • HTTPS adalah bentuk HTTP yang ditambah enkripsi dan verifikasi TLS, dan TLS handshake adalah proses menyelaraskan informasi versi, cipher suite, sertifikat, dan pertukaran kunci untuk membuat symmetric session key
  • TLS 1.3 mengecualikan RSA serta cipher suite dan parameter yang rentan, sekaligus mengurangi pilihan, sehingga membentuk handshake yang lebih sederhana, cepat, dan aman dibanding cara sebelumnya

Model berlapis untuk melihat komunikasi internet

  • Internet adalah jaringan dari berbagai jaringan komputer yang saling terhubung, dan “Internet” secara harfiah berarti “di antara jaringan”
  • Internet bekerja sebagai mesh network berbasis packet switching, dengan struktur best-effort delivery yang tidak menjamin apakah paket akan terkirim atau kapan akan tiba
  • Karena pemrosesan seperti retry, jaminan urutan, penghapusan duplikasi, dan keamanan ditangani di balik layar oleh beberapa lapisan abstraksi, internet tampak berjalan dengan mulus
  • Setiap lapisan menyediakan fungsi tertentu, dan berbagai protokol dapat mengimplementasikan fungsi tersebut
    • Berkat modularisasi ini, mengubah protokol di satu lapisan bisa saja tidak memengaruhi protokol di lapisan lain

Peran tiap lapisan jaringan

  • Application layer menangani logika khusus aplikasi; unit komunikasinya adalah message, dan HTTP adalah contoh utamanya
  • Security layer menyediakan enkripsi dan autentikasi; unit komunikasinya adalah record, dan TLS adalah contohnya
  • Transport layer bertanggung jawab atas transmisi data yang andal; menggunakan TCP segment atau UDP datagram dan diidentifikasi dengan nomor port
  • Network layer merutekan paket melintasi internet; menggunakan alamat IP sebagai identifier
  • Link layer mengelola komunikasi yang dekat dengan media fisik; menggunakan frame dan diidentifikasi dengan alamat MAC
  • Physical layer mentransmisikan bit secara fisik antarperangkat; contohnya serat optik atau Ethernet cable

Alur permintaan HTTP

  • 1. Klien membuat permintaan

    • Proses dimulai di Application layer, dan klien biasanya adalah web browser
    • HTTP adalah protokol berbasis teks, sehingga data dikirim sebagai plaintext
    • Baris pertama permintaan HTTP biasanya berisi HTTP method, resource yang diminta, dan versi protokol
      • HTTP method: GET, POST, dan lain-lain
      • Resource yang diminta: misalnya /index.html
      • Versi protokol
    • Sisa pesan HTTP mencakup header dalam format key: value dan body opsional
    GET /index.html HTTP/1.1
Host: www.example.com
Accept: text/html
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36

  • 2. DNS lookup

    • DNS mengubah nama domain yang dapat dibaca manusia, seperti www.example.com, menjadi alamat IP seperti 93.184.216.34
    • Klien melakukan query ke server DNS untuk me-resolve nama domain menjadi alamat IP
    • Proses ini melewati beberapa resolver hingga akhirnya mencapai authoritative server
    • Stub resolver berada di mesin klien dan meneruskan permintaan ke recursive resolver yang sesuai
    • Recursive resolver menerima permintaan dari stub resolver, melakukan query ke authoritative server, dan sering kali menyimpan hasilnya di cache
    • ISP biasanya menyediakan recursive resolver, dan resolver publik seperti Google DNS 8.8.8.8 juga dapat digunakan
    • Authoritative server memiliki DNS record aktual seperti A, MX, dan CNAME, serta menjadi sumber akhir data nama domain

  • 3. TCP handshake

    • Setelah mendapatkan alamat IP server, klien menyiapkan pengiriman HTTP di Transport layer
    • Protokol utama di lapisan transport adalah TCP dan UDP
    • TCP adalah protokol connection-oriented yang menjamin keandalan, urutan, dan pemeriksaan kesalahan dalam pengiriman data antar-aplikasi
    • UDP adalah protokol connectionless yang tidak menjamin pengiriman, urutan, atau pemeriksaan kesalahan, tetapi cepat dan memiliki overhead rendah
    • Per 2024, TCP adalah protokol utama untuk mengelola transfer data internet, sedangkan UDP terutama digunakan untuk aplikasi real-time yang membutuhkan latensi rendah dan dapat menoleransi sebagian kehilangan paket, seperti streaming atau panggilan video
    • Koneksi TCP dimulai ke port 80, port standar HTTP, melalui handshake 3 tahap
      • SYN: klien mengirim paket SYN untuk meminta koneksi
      • SYN-ACK: server menyetujui permintaan dengan paket SYN-ACK
      • ACK: klien mengirim paket ACK, sehingga koneksi yang andal terbentuk

  • 4. Mengirim permintaan HTTP

    • Setelah koneksi TCP siap, klien mengirim permintaan HTTP yang sebenarnya
    • Karena HTTP adalah protokol berbasis teks, header permintaan dan body, jika ada, dikirim sebagai plaintext

Cara paket sampai ke server

  • Saat klien mengirim permintaan, paket data tidak langsung bergerak ke server, tetapi mencari rute untuk mencapai gateway jaringan server melalui berbagai perangkat jaringan dan router
  • Setelah itu, Link layer bertanggung jawab atas transmisi di segmen lokal

  • Tahapan teks menyeberangi internet

    • Perangkat klien mengenkapsulasi data permintaan HTTP menjadi TCP segment, lalu membungkusnya lagi menjadi IP packet
    • Jika menggunakan koneksi kabel, data tersebut dienkapsulasi sekali lagi menjadi Link layer frame seperti Ethernet frame
    • Frame dikirim melalui jaringan lokal ke router klien
    • Router lokal menerima frame, menghapus Link layer header, lalu memproses IP packet
    • Router melihat alamat IP tujuan dan menentukan hop berikutnya
    • Paket diteruskan ke jaringan berikutnya melalui satu atau lebih router perantara, dan setiap router mengulangi proses menentukan hop berikutnya lalu meneruskannya
    • Paket akhirnya mencapai router yang berada di jaringan yang sama dengan server tujuan
    • Router ini membuat keputusan routing akhir dan mengirim paket ke perangkat lokal yang merupakan server tersebut
    • Router server meneruskan paket ke server melalui segment jaringan lokal
    • Link layer memastikan frame dikirim dengan benar ke antarmuka jaringan server
    • Server menerima frame, mengekstrak IP packet, lalu memproses TCP segment yang dienkapsulasi untuk merekonstruksi permintaan HTTP asli
    • Proses Network layer untuk mengirim paket melintasi internet juga digunakan pada tahap sebelumnya seperti resolusi nama domain atau TCP handshake

Respons server dan rendering browser

  • Server memproses permintaan HTTP lalu mengirim respons HTTP ke klien
  • Respons mencakup versi HTTP yang digunakan, status code seperti 200 atau 404, header respons, serta body seperti HTML halaman yang diminta atau data JSON
HTTP/1.1 200 OK
Date: Sat, 26 May 2023 10:00:00 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Type: text/html
Content-Length: 3456

    Example Page

    Hello, world!
  • Klien menerima dan memproses respons HTTP
  • Browser menginterpretasikan HTML dan merender konten di layar
  • Jika respons memiliki resource tambahan seperti gambar, CSS, atau JavaScript, browser mengirim permintaan HTTP tambahan dengan mengikuti proses yang sama

Masalah keamanan HTTP dan HTTPS

  • HTTP dasar tidak memiliki keamanan sama sekali
  • Siapa pun yang mendengarkan koneksi dapat melihat 100% data yang dikirim dan diterima
  • Jika seseorang berpura-pura menjadi server, klien dapat mengirim informasi penting ke target yang salah
  • HTTPS adalah bentuk HTTP yang ditambah enkripsi dan verifikasi
  • Ada beberapa cara untuk membuat komunikasi HTTP aman, tetapi implementasi yang umum digunakan saat ini adalah TLS
  • TLS memungkinkan klien dan server memverifikasi identitas satu sama lain, serta mengenkripsi payload dengan cara yang dapat didekripsi oleh kedua pihak
  • Alur permintaan HTTPS sama dengan alur permintaan HTTP yang telah dibahas, tetapi Security layer ditambahkan di antara Application layer dan Transport layer
    • TLS handshake biasanya menggunakan TCP

Apa yang disepakati dalam TLS handshake

  • TLS handshake adalah proses ketika klien dan server menyepakati berbagai elemen yang akan digunakan untuk komunikasi
  • Hal yang disepakati mencakup kumpulan algoritme untuk verifikasi pesan, kompresi, dan enkripsi
  • Kumpulan algoritme ini disebut cipher suite
    • Secara ketat, cipher suite mencakup semuanya kecuali compression algorithm, tetapi dalam tulisan ini seluruh kumpulan disebut cipher suite
  • Contoh komponennya adalah sebagai berikut
    • Compression algorithm: cara mengompresi data di wire; contohnya Gzip dan Brotli, dan saat ini Brotli terutama digunakan
    • Key exchange algorithm: cara bertukar kunci enkripsi secara aman melalui kanal publik; contohnya ECDHE-RSA dan ECDHE-ECDSA, dan saat ini ECDHE terutama digunakan
    • Authentication algorithm: cara mengautentikasi identitas pihak selama handshake; contohnya RSA dan ECDSA, RSA digunakan luas dan ECDSA juga semakin populer
    • Symmetric encryption algorithm: cara mengenkripsi data antara klien dan server; contohnya AES-128-GCM dan AES-256-GCM, dan AES-GCM menyediakan keamanan kuat sekaligus efisiensi
    • MAC algorithm: cara menjamin integritas dan keaslian pesan; contohnya HMAC-SHA256 dan HMAC-SHA384, dan HMAC-SHA256 serta GCM mode pada cipher suite modern digunakan
  • Klien dan server menyepakati cipher suite, lalu bertukar random seed dan informasi SSL certificate agar dapat membuat symmetric key yang digunakan untuk enkripsi dan verifikasi pesan
  • Sumber materi TLS handshake adalah Cloudflare

Tahapan TLS handshake lama

  • Client Hello

    • Klien mengirim pesan TCP ke server yang berisi cipher suite yang didukung, TLS version yang didukung, dan bilangan acak bernama Client Random

  • Server Hello

    • Server merespons dengan pesan TCP yang berisi TLS version yang dipilih, algoritme cipher suite yang dipilih, dan Server Random

  • Certificate Verification

    • Klien memverifikasi SSL certificate server melalui Certificate Authority dan mengambil public key server

  • Premaster Secret Generation

    • Klien membuat premaster secret, mengenkripsinya dengan public key server, lalu mengirimkannya ke server

  • Decryption

    • Server menggunakan private key untuk mendekripsi premaster secret

  • Session Key Creation

    • Klien dan server menggunakan Client Random, Server Random, dan premaster secret untuk membuat session key

  • Client Ready

    • Klien mengirim pesan finished yang dienkripsi dengan session key

  • Server Ready

    • Server mengirim pesan finished yang dienkripsi dengan session key

  • Secure HTTP Communication

    • Setelah itu, kedua pihak berkomunikasi menggunakan enkripsi simetris yang aman dengan session key

Perubahan di TLS 1.3

  • TLS handshake yang dijelaskan sebelumnya adalah proses untuk versi TLS lama, dan sudah menjadi cara yang usang jika mengacu pada TLS 1.3 terbaru
  • TLS 1.3 ke atas tidak mendukung RSA dan banyak cipher suite karena alasan keamanan
  • Versi terbaru sangat mengurangi pilihan sehingga lebih sederhana, lebih aman, dan lebih cepat
  • Konsep inti tetap dipertahankan di TLS 1.3
    • Melalui handshake, disepakati metode kompresi, autentikasi server, dan pertukaran kunci
    • Symmetric encryption key dibuat untuk melindungi data paket yang dipertukarkan melalui TCP
  • TLS 1.3 tidak mendukung cipher suite dan parameter yang rentan terhadap serangan, serta mempersingkat handshake sehingga menghasilkan handshake yang lebih cepat dan aman

  • Tahapan dasar TLS 1.3 handshake

    • Client hello: klien mengirim versi protokol, Client Random, dan daftar cipher suite
      • Di TLS 1.3, dukungan untuk cipher suite yang tidak aman dihapus sehingga jumlah cipher suite yang mungkin jauh berkurang
      • Client hello juga mencakup parameter yang akan digunakan untuk menghitung premaster secret
      • Klien mengasumsikan bahwa ia mengetahui key exchange method yang disukai server, dan karena daftar cipher suite yang berkurang, kemungkinan ini lebih tinggi
      • Struktur ini mengurangi panjang total handshake dibanding TLS 1.0, 1.1, dan 1.2
    • Server generates master secret: server telah menerima Client Random, parameter klien, dan cipher suite, serta dapat membuat Server Random sendiri, sehingga dapat membuat master secret
    • Server hello and Finished: Server hello mencakup server certificate, digital signature, Server Random, dan cipher suite yang dipilih
      • Karena server sudah memiliki master secret, ia juga mengirim pesan Finished bersamaan
    • Final steps and client Finished: klien memverifikasi signature dan certificate, membuat master secret, lalu mengirim pesan Finished
    • Secure symmetric encryption achieved: setelah itu, enkripsi simetris yang aman terbentuk

Bacaan terkait

1 komentar

 
GN⁺ 2024-05-27
Komentar Hacker News

  • Sebagai orang nonspesialis saya penasaran, kenapa saat tidak bisa mengakses situs web tertentu atau bahkan seluruh internet, di bagian mana gangguan terjadi begitu sulit diketahui
    Sering kali tidak jelas apakah penyebabnya adalah kesalahan pengaturan jaringan di mesin lokal saya, masalah koneksi Wi-Fi ke router, masalah kabel antara router dan ISP, gangguan besar di ISP, atau gangguan di situs web yang ingin diakses
    Saya pernah mendengar penjelasan samar bahwa ini karena permintaan dirutekan melalui jalur yang tidak deterministik, tetapi rasanya kurang meyakinkan. Kalau ada link di tengah jalur yang putus, saya jadi bertanya kenapa link terakhir yang masih normal tidak bisa memberi tahu balik, “pesanmu sampai di sini, tetapi gagal diteruskan ke tahap berikutnya”

    • Kalau paham cara kerjanya, memang bisa diketahui dengan cukup tepat apa yang gagal, tetapi hampir mustahil membuat alat diagnostik yang memberi penjelasan yang benar-benar berguna bagi pengguna
      Konfigurasinya beragam, tidak ada cara pasti untuk tahu susunan mana yang memang dimaksudkan, dan berbahaya jika kita berasumsi berdasarkan penyebab umum lalu memberikan jawaban yang ternyata sama sekali salah
      Misalnya, kalau server DNS juga tidak merespons dan host tujuan juga tidak merespons, kita mungkin akan bilang ini kesalahan konfigurasi router atau gangguan ISP. Namun penyebab sebenarnya bisa saja klien VPN mengubah routing table lokal dan server DNS lalu gagal mengembalikannya saat keluar. Masalahnya, bagaimana alat diagnosis bisa tahu apakah itu perubahan sementara atau pengaturan permanen
    • Jika ICMP diizinkan masuk ke jaringan, kemungkinan besar Anda akan menerima respons Destination Unreachable dari host yang tidak dapat meneruskan paket lebih jauh
      Aplikasi tidak akan melihat pesan ICMP kecuali soketnya diatur untuk itu. Hal seperti ini diperlakukan sebagai error “sementara”, dan di Linux diatur dengan opsi soket IP_RECVERR
      Saat bekerja di layer 7, mengumpulkan error dari layer ini biasanya tidak terlalu bernilai. Error Destination Unreachable yang muncul ke atas pada akhirnya akan menyesuaikan dengan logika penanganan kegagalan yang sudah Anda miliki, dan dalam kasus ini layer lain akan mencoba ulang tujuan yang tidak dapat dijangkau, sehingga kemungkinan besar akan terlihat sebagai timeout
      RFC ini membantu menjelaskan bagaimana layer TCP menangani error ICMP: https://www.rfc-editor.org/rfc/rfc1122#page-103
      Di 4.2.3.9 dijelaskan bahwa pesan Unreachable adalah kondisi soft error sehingga TCP tidak boleh memutus koneksi, tetapi harus menyediakan informasinya ke aplikasi. TCP bisa meneruskannya ke layer aplikasi lewat rutinitas ERROR_REPORT, atau mencatat pesannya lalu melaporkannya ke aplikasi hanya ketika koneksi TCP timeout
      Ada juga dokumen yang membahas lebih rinci bagaimana stack saling berinteraksi untuk meneliti ICMP sebagai vektor serangan terhadap TCP: https://www.rfc-editor.org/rfc/rfc5927
    • Browser melaporkan error yang paling dekat dengan pekerjaan yang sedang dilakukan saat itu. Jika host tidak ditemukan, itu kurang lebih berarti server DNS berhasil dijangkau dan server tersebut menjawab bahwa tidak ada alamat untuk nama itu
      Jika server DNS itu sendiri tidak bisa dijangkau, berarti ada error jaringan di suatu titik antara pengguna dan server tersebut. Biasanya diagnosis dilakukan dengan menjalankan langkah-langkahnya sendiri: periksa apakah alamat server DNS bisa di-ping, apakah host tersebut bisa di-resolve lewat server DNS itu, dan bagaimana hasilnya di server DNS lain. Bisa juga ada nama tertentu yang dikecualikan karena kebijakan perusahaan
      Kalau ingin menggali lebih jauh, alat baris perintah seperti ping, traceroute, dan dig sangat berguna
    • Banyak dari masalah seperti ini selama ini saya pecahkan dengan menjalankan MTR ke tujuan saat troubleshooting, lalu melihat detail setiap hop
      MTR seperti gabungan ping + traceroute yang berjalan terus secara real-time, dan setiap hop ditampilkan terpisah
      Saat pertama kali mengetahui ada node mati di jaringan Xfinity pun hasilnya konsisten, karena dari MTR yang sama saya setidaknya bisa melihat bahwa jaringan saya sendiri sampai modem masih normal. Saya juga belum banyak melihat alat lain yang sebaik MTR dalam menunjukkan hop mana di luar ISP yang latensinya melonjak ratusan ms
      Memang tidak menyelesaikan semua masalah, tetapi karena memberikan latensi per hop, ini layak diperiksa
    • Penting juga apa yang sebenarnya ingin Anda periksa. Jika browser web tidak bisa mengakses sebuah URL tetapi tidak memberi tahu penyebab pastinya, itu karena diagnosisnya bisa salah dan kebanyakan pengguna justru akan bingung
      Untuk bisa bilang “masalahnya ada di sini”, kita harus membuat asumsi tentang bagaimana sistem operasi, hardware, dan jaringan dikonfigurasi
      Saat mengakses situs web, pertama-tama kita harus mendapatkan alamat IP server web dari DNS, tetapi dari mana browser memperoleh IP DNS saja sudah rumit. Itu bisa diatur di browser, sistem operasi, router, atau modem, dan kalau tidak diatur maka akan didapat dari server DHCP yang terhubung ke router. Server itu bisa jadi server DHCP milik ISP, atau router lain di dalam organisasi
      Jika DNS tampak bermasalah, memang mudah mengetahui bahwa IP-nya salah, tetapi sulit mengatakan IP itu berasal dari mana. Pada SSL pun, bisa saja sertifikat server yang salah, atau justru sertifikat di komputer saya yang salah

  • Ini mungkin relevan, ada juga contoh interaktif yang mengikuti TLSv1.2 dan TLSv1.3 secara sangat rinci sampai tingkat byte
    Saya sangat menyukai materi ini jika ingin belajar TLS lebih jauh, jadi sangat saya rekomendasikan
    [0]: https://tls12.xargs.org/
    [1]: https://tls13.xargs.org/

  • Saya penasaran apakah ada lebih banyak contoh tulisan dengan sudut pandang seperti ini. Saya suka tulisan yang menguraikan sesuatu seolah-olah menjelaskannya kepada engineer yang biasa-biasa saja, terlepas dari tingkat kemahirannya.
    Biasanya sangat berguna karena saya bisa mempelajari ulang potongan yang sebelumnya belum sepenuhnya jelas, atau mendapatkan lebih banyak contoh untuk dipakai saat menjelaskannya kepada orang lain.

  • Penjelasan bahwa “klien membuat premaster secret, mengenkripsinya dengan kunci publik server, lalu mengirimkannya ke server” sudah lama bukan fakta

    • Di bawahnya tertulis “semua yang dipelajari di sini adalah bohong”
      Ditambahkan bahwa proses yang baru saja dijelaskan itu adalah proses versi awal TLS yang sudah usang jika dibandingkan dengan TLS 1.3 modern

  • Pernyataan “versi TLS saat ini (>1.3) tidak mendukung RSA dan berbagai cipher suite karena alasan keamanan” itu benar untuk bagian pertukaran kunci. Alasannya, RSA tidak memberikan forward secrecy
    Untuk tanda tangan, RSA masih dipakai, dan mungkin masih menjadi jenis yang paling luas digunakan di sertifikat x509
    Setahu saya Safari juga belum lama ini menaikkan persyaratan kunci menjadi 2048 bit untuk tanda tangan RSA

  • Tulisan ini terbaca seperti ringkasan buatan AI atas tulisan penjelasan HTTPS yang sebenarnya. Istilah-istilah muncul tanpa konteks
    Tidak dijelaskan apa itu sertifikat, bagaimana rantai kepercayaan bekerja, dan diasumsikan pembaca sudah paham kriptografi kunci publik. Dari 7 lapisan OSI, 6 dijelaskan tetapi istilah itu sendiri tidak disebutkan, dan lapisan presentasi juga dilewatkan
    Tentu saja, dari judulnya sendiri sudah dibilang mediocre

    • Agar adil, lapisan sesi juga tidak dimasukkan
      Menulis memang bukan kekuatan saya, jadi saya menerima kritik itu dengan senang hati. Tulisan saya naik level dari “buruk” menjadi “ini AI ya?” itu sudah kemajuan
      Saya memang memikirkan di mana penjelasan sebaiknya dipotong, dan saya menganggap kriptografi kunci publik sebagai batas yang bagus untuk dijelaskan lebih baik di tempat lain. Hal yang sama juga berlaku untuk beberapa lapisan OSI
      Saya akui bahwa sertifikat dan mungkin seluruh rantai kepercayaan seharusnya memang dibahas

  • Saya tidak bisa menemukan kode yang menunjukkan verifikasi tanda tangan untuk SHA256(client_hello_random + server_hello_random + curve_info + public_key)
    Secara teori saya paham, tetapi saat mencoba mengimplementasikannya selalu ada yang bermasalah. Akan bagus kalau ada tautan ke program mainan yang menunjukkan bagaimana melakukannya dalam praktik

  • Tolong jangan sampai ada ungkapan seperti “sertifikat SSL server berisi kunci privat”. Tapi ya judulnya memang “Mediocre Engineer”
    Bahkan TLS <1.3 pun tidak bekerja seperti yang digambarkan di tulisan itu, tetapi di saat yang sama ia mencoba mencampurkan unsur-unsur yang lebih baru dari 1.3. Bagian DNS menjelaskan recursive resolver, padahal klien tidak bekerja seperti itu; kemungkinan ia akan berkomunikasi dengan stub resolver
    Kesalahan seperti “Internet Layer”, implikasi bahwa brotli adalah algoritme yang luas dipakai untuk kompresi TLS atau cipher suite, dan “versi TLS saat ini (>1.3) tidak mendukung RSA” terus bermunculan
    Gara-gara blogspam seperti ini, kadang saya berharap ada tombol downvote. Tidak cukup mengganggu untuk ditandai sebagai iklan, tetapi mutunya rendah. Mungkin saya malah harus menulis artikel yang kurang mediocre lalu membawanya ke halaman depan HN. Kalau gaji saya $300K, mungkin saya akan punya lebih banyak waktu

  • Isi tulisannya secara keseluruhan agak usang. Sekarang 30% permintaan web adalah HTTP/3 dan juga ada CORS, tetapi tidak ada tanggal publikasi

    • Maksudnya 30% dari permintaan adalah CORS? Itu akan sangat bergantung pada jenis pengembangan yang dilakukan
      Saya biasanya mengembangkan sistem SaaS yang di-deploy di dalam jaringan perusahaan, dan permintaan CORS hampir mendekati 0%. Hal yang sama juga berlaku untuk HTTP/3