HTTPS adalah saluran HTTP yang dirancang untuk keamanan, memberikan perlindungan lebih baik bagi transmisi konten melalui CDN. Saat mengakses konten berkecepatan tinggi, klien dapat menjelajahi konten situs web secara lebih aman dan efektif. Topik ini menyediakan jawaban atas pertanyaan umum mengenai HTTPS.
Dasar-dasar dan prinsip HTTPS
Apa saja jenis serangan HTTP yang umum?
Berikut ini adalah jenis-jenis serangan HTTP yang umum:
Injeksi SQL: Penyerang mengeksploitasi aplikasi yang rentan untuk menyisipkan perintah SQL berbahaya ke dalam mesin database backend guna dieksekusi. Mereka juga dapat memasukkan pernyataan SQL berbahaya melalui formulir web untuk mengakses database situs web yang memiliki kerentanan keamanan, alih-alih mengeksekusi pernyataan SQL sesuai rancangan pengembang.
Cross-site scripting: Cross-site scripting (XSS) merupakan salah satu metode paling umum dan mendasar untuk menyerang situs web. Penyerang memublikasikan data yang berisi kode berbahaya pada halaman web. Ketika pengguna membuka halaman tersebut, skrip tertentu dijalankan dengan identitas dan izin pengguna yang sedang menjelajah. XSS mempermudah manipulasi data pengguna dan pencurian informasi pengguna.
Cross-site request forgery: Cross-site request forgery (CSRF) adalah serangan umum lainnya. Penyerang memalsukan permintaan dengan berbagai cara untuk meniru perilaku pengguna saat mengirimkan formulir, demi memanipulasi data pengguna atau menjalankan tugas tertentu. Untuk menyamar sebagai pengguna, serangan CSRF dan XSS biasanya bekerja sama, tetapi penyerang juga dapat menggunakan cara lain, misalnya, mengelabui pengguna agar mengklik tautan berbahaya.
Serangan header HTTP: Saat Anda menggunakan browser untuk mengunjungi situs web apa pun, terlepas dari teknologi dan framework yang digunakan, protokol HTTP selalu terlibat. Dalam protokol HTTP, terdapat baris kosong antara header respons dan konten, yaitu dua set karakter CRLF (0x0D 0x0A). Baris kosong ini menandai akhir header dan awal konten, yang dapat dieksploitasi oleh penyerang. Selama penyerang dapat menyisipkan karakter arbitrer ke dalam header, serangan ini dapat terjadi.
Serangan pengalihan: Serangan yang umum digunakan adalah penipuan phishing. Pelaku phishing biasanya mengirim korban tautan yang tampak sah. Ketika korban mengunjungi tautan tersebut, mereka dialihkan ke situs web berbahaya sehingga pelaku mendapatkan kepercayaan mereka dan mencuri informasi mereka. Untuk mencegah hal ini, semua operasi pengalihan harus divalidasi agar tidak mengarahkan ke tujuan berbahaya. Solusi umum adalah daftar putih: tambahkan URL pengalihan yang sah ke daftar putih dan tolak pengalihan ke domain yang tidak ada dalam daftar putih. Solusi kedua adalah token pengalihan: tambahkan token ke URL yang sah dan validasi token tersebut saat pengalihan.
Apakah mengaktifkan percepatan HTTPS mengonsumsi lebih banyak sumber daya atau memperlambat akses?
Ketika HTTPS diaktifkan pada origin, konsumsi sumber daya komputasi meningkat dibandingkan akses HTTP ke origin. Peningkatan ini terutama berasal dari enkripsi dan dekripsi asimetris selama handshake HTTPS, serta konsumsi sumber daya meningkat signifikan dalam kondisi konkurensi tinggi. Konsumsi enkripsi dan dekripsi simetris pada dasarnya sama dengan HTTP, sehingga tingkat penggunaan ulang sesi sebaiknya ditingkatkan. Namun, mengakses origin langsung melalui HTTPS membutuhkan waktu lebih lama dibandingkan mengakses origin langsung melalui HTTP. Untuk konten statis, distribusi edge mengurangi waktu transmisi meskipun ada tambahan waktu handshake, sehingga waktu akses keseluruhan berkurang. Selain itu, sumber daya statis tidak perlu diambil dari origin, yang mengurangi interaksi dengan origin dan menurunkan konsumsi sumber daya di origin.
Skenario penggunaan dan pertimbangan HTTPS
Apakah HTTPS hanya diperlukan untuk login situs?
Tidak. Anda perlu menganalisis hal ini dari aspek-aspek berikut:
Keamanan: Jika beberapa halaman menggunakan HTTP dan beberapa halaman lainnya menggunakan HTTPS, ketika sumber daya lain (seperti file JS atau CSS) dimuat melalui HTTP atau melalui layanan CDN yang tidak aman, situs web tetap menghadapi risiko kebocoran informasi pengguna. HTTPS menyeluruh di seluruh situs merupakan cara paling sederhana untuk mencegah risiko ini.
Kinerja: Ketika sebuah situs web mendukung HTTPS dan HTTP sekaligus, pergantian antar protokol memerlukan banyak pengalihan di sisi server, dan ketika pengalihan ini dipicu, pemuatan halaman menjadi lebih lambat.
Ekosistem web: Browser lebih mendukung HTTPS, dan mesin pencari memberikan dukungan pengindeksan yang lebih baik untuk situs HTTPS.
HTTPS sudah dikonfigurasi di origin. Apakah saya tetap perlu mengonfigurasi HTTPS di CDN?
HTTPS adalah interaksi antara klien dan server. Sebelum CDN digunakan, klien berinteraksi langsung dengan origin, sehingga HTTPS harus dikonfigurasi di origin. Setelah CDN digunakan, klien berinteraksi dengan CDN. Jika Anda ingin mengakses CDN melalui HTTPS, Anda harus mengonfigurasi sertifikat HTTPS di CDN. Untuk informasi tentang cara mengonfigurasi sertifikat HTTPS di CDN, lihat Konfigurasikan sertifikat HTTPS.
Sertifikat HTTPS di origin telah diperbarui. Apakah sertifikat di CDN perlu diperbarui juga?
Tidak. Sertifikat HTTPS di server origin dan sertifikat HTTPS di CDN saling independen. Memperbarui sertifikat di origin tidak memengaruhi sertifikat HTTPS di CDN. Anda hanya perlu memperbarui sertifikat HTTPS di CDN jika sertifikat yang dikonfigurasi di CDN akan kedaluwarsa atau sudah kedaluwarsa. Untuk informasi lebih lanjut, lihat Konfigurasikan sertifikat HTTPS.
Apakah port origin berubah setelah sertifikat HTTPS dikonfigurasi?
Mengonfigurasi sertifikat HTTPS untuk nama domain yang dipercepat tidak secara langsung memengaruhi port origin, tetapi secara tidak langsung memengaruhi port origin dalam mode mengikuti protokol. Aturan spesifiknya adalah sebagai berikut:
1. Mengonfigurasi sertifikat HTTPS sendiri tidak berkaitan dengan port origin
Sertifikat HTTPS hanya menyediakan enkripsi antara klien dan node CDN. Ini tidak mengubah protokol atau port origin antara CDN dan origin. Perilaku origin dikendalikan secara independen oleh pengaturan protokol origin: ketika diatur ke HTTP, CDN mengambil konten dari origin melalui port 80 secara default; ketika diatur ke HTTPS, CDN mengambil konten dari origin melalui port 443 secara default. Hal ini tidak terkait dengan apakah sertifikat dikonfigurasi di edge atau tidak.
2. Ketika protokol origin diatur untuk mengikuti, maka dipengaruhi oleh protokol akses klien
Setelah sertifikat HTTPS dikonfigurasi dan percepatan aman HTTPS diaktifkan, CDN mendukung akses melalui HTTP maupun HTTPS;
Jika protokol origin diatur untuk mengikuti klien: ketika klien mengakses CDN melalui HTTP, CDN mengambil konten dari origin melalui port 80; ketika klien mengakses CDN melalui HTTPS, CDN mengambil konten dari origin melalui port 443.
3. Jika enkripsi HTTPS end-to-end diperlukan
Hanya mengonfigurasi sertifikat edge tidak cukup. Anda juga harus mengatur protokol origin ke HTTPS dalam pengaturan origin, dan pastikan bahwa origin mendukung akses HTTPS.
Untuk informasi tentang cara mengonfigurasi protokol origin, lihat Konfigurasikan kebijakan protokol asal.
Konfigurasi dan unggah sertifikat
Saat mengunggah sertifikat pihak ketiga yang berisi beberapa file .crt, bagaimana cara mengunggah sertifikat tersebut?
File sertifikat yang dikeluarkan oleh otoritas sertifikat perantara berisi beberapa sertifikat. Anda harus menggabungkan sertifikat server dan sertifikat perantara menjadi satu sertifikat lengkap sebelum mengunggah.
Buka semua file sertifikat dalam format *.PEM menggunakan editor teks. Tempatkan sertifikat server terlebih dahulu, diikuti oleh sertifikat perantara. Tidak boleh ada baris kosong di antara sertifikat-sertifikat tersebut. Dalam kebanyakan kasus, otoritas sertifikat menyediakan petunjuk yang sesuai saat menerbitkan sertifikat. Ikuti petunjuk tersebut.
Sertifikat yang digabungkan adalah sebagai berikut.
-----BEGIN CERTIFICATE-----
MIIE/DCCA+SgAwIBAgIUOWvvEj41j5OamNabjVbGY42BBcQwDQYJKoZIhvcNAQEL
BQAwgYIxCzAJBgNVBAYTAnNuMRIwEAYDVQQIDALHdWFuZORvbmcxETAPBgNVBAcM
CFNgZWS6aGVuMQ8wDQYDVQQKDAZIdWF3ZWkxCzAJBgNVBAsMAklMS4wLAYDVQQD
DCVIdWF3ZWkgV2ViIFN1Y3VyaXR5IEJOQ1NBIFJvb3QgQ0EgVjMxCzAJBgNVBAYT
ODAwNDAO1oXDTE4MTAxODAwNDAO1owGZoxCzAJBgNVBAYTAkNOMRAwDgYDVQQI
DAdqeWFuZ3N1M1MRAwDgYDVQQHDAdUYW5qeWFuZzELMAkGA1UECgwCVzGxGzAYBgNVBAsMEVdl
dHdhcmVGVjG5bG93Z2oxCzAJBgNVBAYTAkNOMRAwDgYDVQQIDAd5dWEwZ3N1M9
9wOBAAEFAOCAQ8AMIIBCgKCAQEA1hC5fG6J2OX5F/YW7bo6130yzgaWVGLEX8t
1dQ1JAus93xMC2Jr6UOXmXR6WaRu51ZxpPfLT/IV6UnvMLnxJQBavqeUykCSkadW
stYA9ttTI/FYq+MR1XKbNzqK/ADhRfmR4ovS/3w1wxvdpwySfR2+V/D6TjxHZCjc
+81SmUuLxsgoUe79B/ruccY1ufuqr3v0TToaNn4c37kwjJeKf+b2F/IqO/KF+9zF
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
AgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMBIGA1UdEQQ7MDmCE3d3dy5odWF3ZW1j
bG91ZC5jb22CESouaHVhd2VpY2xvdWQuY29tgg9odWF3ZW1jbG91ZC5jb20wDQYJ
KoZIhvcNAQELBQADggEBAcsLP7Hj+4KY1ES38On0UuvQ3st8axvhDD9jZGoninzW
JSGpdm04NEsh1vwSFdEHpjy/xKSLCIqg5Ue8tTI8zoF13U0R0nMeHSKsxJG6zc8X
h/3N217oBygFgvpmc6YX66kvuXmkA7KRniiYS0nmCi2KUyngSBv4dsk21dj1lqQ3b
HI+1o26Q9odLsmhsKOsFUC0vDKoMIJz0Socy7Cq1+tFWF9S79MI4QjxaXEVvpIEg
QLEze3BXSsoiWRkdfasdDB9s+UtdWeJyOHMh/otvUQCtB6areV2+CPthmDENA+A8
IK6GzHyp/mgrzwKdDh97aQ42ARreAv4KVFAiJGZO2LOY=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIID2TCCAsSgAwIBAgIJALQPO9xFFzmA0GCSqGSIb3DQEBCwUAMIGCMQswCQYD
VQQGEwJjbjESMBAGA1UECAwJR3Vhbm1dEb2SnMREwDwYDVQQHDAhTaGVuemhlbjEP
MA0GA1UECgwGSHVhd2VpMQswCQYDVQQLDAJJVDEuMCwGA1UEAwwlSHVhd2VpIFdl
YiBTZWN1cmUgSW50ZXJuZXQgR2F0ZXdheSBDQSBWMzELMAkGA1UEBhMCQ04xEjAQ
BgNVBAgMCUd1YW5nZG9uZzERMA8GA1UEBwwIU2hlbnpoZW4xDzANBgNVBAoMBkh1
YWdlaTELMAkGA1UECwwCSVQxLjAsBgNVBAMMJUh1YXdlaSBXZWIgU2VjdXJpdHkg
RUJDU0EgUm9vdCBDQSBWMzELMAkGA1UEBhMCQ04wHhcNMTgxMDE4MDAwMDAwWhcN
MREwDwYDVQQHDAhTaGVuemhlbjEPMA0GA1UECgwGSHVhd2VpMQswCQYDVQQLDAJJ
VDEuMCwGA1UEAwwlSHVhd2VpIFdlYiBTZWN1cmUgSW50ZXJuZXQgR2F0ZXdheSBD
QSBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL
IwQYMBaFDB6DZZX4Am+isCoa48e42drAXpsMAwGA1UdEwQFMAMBAf8wDQYJKoZI
hvcNAQELBQADggEBAKN9k5jRX56jw2Ku5Mn3gZu/kQQw+mLkIuJEeDwS6LMjWOHv
313x1v/Uxv4hQmo6OXqg2OM4dfIJoVVKgiLlBCpXv0/X600rq3UPediEMaXkmM+F
tuJnoPCXmew7QvvQQwis+0xmhpRPgON6xIK01vIbAV69TkpwJW3duj1FuRgSvn
Rab4gVi14x+bUgTbGHCvDH99PhAdvXOuI1mk5Kb/JhCNbhRAHezyfLrvimxI0Ky
2KWZitN+M1UWvSYG8j3mtDm+/FuA93V1yEzRjKj92egCgM1u671liddt7zzzzqW+U
QLUOevUmUHQsV5mk62v1e8sRViHB1B2HJ3DU5gE=
-----END CERTIFICATE-----Perilaku akses HTTPS dan kompatibilitas
Saat mengonfigurasi HSTS, setelah mengaktifkan include subdomains, apakah saya perlu mengaktifkan HSTS di subdomain?
Anda tidak perlu mengaktifkan HSTS di subdomain. Setelah Anda mengaktifkan Include Subdomains, kebijakan HSTS berlaku untuk semua subdomain. Pastikan setiap subdomain mendukung akses HTTPS normal. Jika tidak, subdomain tersebut akan menjadi tidak dapat diakses.
HTTPS sudah dikonfigurasi. Mengapa klien masih mengakses situs melalui HTTP?
Apakah klien mengakses situs melalui HTTP atau HTTPS sepenuhnya merupakan perilaku klien. Jika Anda ingin memaksa klien menggunakan akses HTTPS, Anda dapat mengaktifkan pengalihan HTTPS paksa di CDN. Untuk informasi lebih lanjut, lihat Konfigurasikan pengalihan HTTP/S.
Mengapa sebagian besar perangkat dapat mengakses nama domain yang dipercepat melalui HTTPS, sedangkan beberapa perangkat tidak dapat?
Hal ini terutama karena CDN mengandalkan SNI saat memproses permintaan HTTPS. SNI adalah ekstensi protokol TLS yang memungkinkan klien menentukan hostname yang ingin dikunjungi saat memulai permintaan koneksi HTTPS.
Namun, beberapa klien lama atau dikonfigurasi khusus (misalnya, versi Android atau iOS lama, Java 6 dan sebelumnya, serta beberapa perangkat IoT) mungkin tidak mendukung SNI, atau tidak mengirimkan informasi SNI saat memulai permintaan HTTPS. Dalam kasus ini, node CDN tidak dapat menentukan situs yang tepat yang ingin dikunjungi klien dan karenanya tidak dapat menyediakan sertifikat SSL/TLS yang benar. Akibatnya, upaya koneksi HTTPS gagal, dan pengguna tidak dapat mengakses konten situs web.
Untuk memperbaiki situasi ini, kami merekomendasikan langkah-langkah berikut:
Perbarui sistem klien: Pastikan sistem operasi dan perangkat lunak yang digunakan selalu mutakhir agar mendukung SNI.
Perbarui firmware perangkat IoT: Untuk perangkat IoT, periksa dan instal pembaruan firmware terbaru yang disediakan oleh produsen secara berkala.
Penagihan HTTPS
Apakah ada biaya tambahan setelah mengaktifkan percepatan HTTPS di CDN?
Ya. Mengaktifkan percepatan HTTPS di CDN sebenarnya mengaktifkan HTTPS pada tautan antara klien dan node edge CDN. Karena handshake SSL dan dekripsi konten keduanya memerlukan komputasi, konsumsi sumber daya CPU server CDN meningkat. Namun, konsumsi sumber daya di server origin Anda tidak meningkat, karena tautan antara node edge CDN dan origin Anda tetap menggunakan protokol HTTP dan tidak menambahkan beban ekstra ke origin Anda.
Jika Anda membeli jenis sertifikat yang berbeda, biaya tambahan diperlukan. Anda juga dapat login ke Konsol Layanan Manajemen Sertifikat untuk mengajukan sertifikat uji coba (edisi gratis), yaitu sertifikat tingkat DV. Anda dapat mengajukan satu sertifikat uji coba untuk setiap nama domain yang dipercepat. Sertifikat tersebut berlaku selama tiga bulan dan dapat diperpanjang secara otomatis tanpa biaya. Setelah mengonfigurasi sertifikat HTTPS, CDN menagih semua permintaan HTTPS untuk domain tersebut. Untuk informasi tentang biaya permintaan HTTPS statis, lihat Penagihan permintaan HTTPS untuk konten statis.
Saat permintaan terkena blacklist IP atau blacklist User-Agent, atau saat permintaan mengembalikan kode status 403/404, apakah permintaan HTTPS tetap ditagih?
Permintaan HTTPS tetap ditagih. Ketika permintaan terkena aturan kebijakan tertentu dan mengembalikan kode status 403 atau 404, permintaan tersebut telah direspons dengan benar, sehingga dihitung sebagai satu permintaan HTTPS. Karena permintaan semacam ini tidak membawa konten sumber daya apa pun, trafik yang ditagih sangat kecil.