Apakah data GET juga dienkripsi dalam HTTPS?

Jawaban:

146

Seluruh permintaan dienkripsi, termasuk URL, dan bahkan perintah ( GET). Satu-satunya hal yang dapat diperoleh pihak yang mengintervensi seperti server proxy adalah alamat dan port tujuan.

Namun, perlu diketahui bahwa paket Halo Klien dari jabat tangan TLS dapat mengiklankan nama domain yang sepenuhnya memenuhi syarat dalam plaintext melalui ekstensi SNI (terima kasih @hafichuk), yang digunakan oleh semua browser arus utama modern, meskipun beberapa hanya pada OS yang lebih baru.

EDIT: (Karena ini hanya memberi saya lencana "Jawaban Baik", saya kira saya harus menjawab seluruh pertanyaan ...)

Seluruh respons juga dienkripsi; proxy tidak dapat memotong bagian mana pun dari itu.

Google melayani pencarian dan konten lainnya melalui https karena tidak semuanya publik, dan Anda mungkin juga ingin menyembunyikan beberapa konten publik dari MITM . Dalam hal apa pun, yang terbaik adalah membiarkan Google menjawab sendiri .

— Marcelo Cantos
sumber
2
Saya sedikit tidak senang dengan klaim bahwa URL dienkripsi. Bukankah nama host dianggap sebagai bagian dari url? Jika demikian, pernyataan itu salah. Tidak ada cara untuk menyembunyikan hostname / alamat IP dari ISP / server proxy dengan cara yang sama Anda tidak dapat menyembunyikan alamat tujuan saat mengirim surat fisik.
— Abhishek Anand
1
@Abhishek: Hostname tidak ada di header TCP / IP. Saya membahas alamat IP dalam jawaban saya.
— Marcelo Cantos
Domain tidak dienkripsi. Ini untuk mendukung host virtual berbasis nama (berbasis IP). @ MarsceloCantos sepenuhnya benar bahwa sisa URL (yaitu GETperintah) dienkripsi. Ini tercakup dalam RFC 4366
— hafichuk
@ hafichuk: Terima kasih untuk itu. Saya tidak menyadari TLS dapat mengiklankan fqdn. Terakhir kali saya mencoba mengatur multiserver https (beberapa tahun yang lalu, saya akui), sepertinya tidak mungkin melalui satu ip.
— Marcelo Cantos
Tambahan yang sangat penting untuk TLS yang berisi nama domain: Jangan lupa permintaan DNS plaintext juga termasuk nama domain. Peluangnya adalah seseorang yang dapat melihat lalu lintas HTTPS terenkripsi Anda juga dapat menonton permintaan DNS Anda.
— Tim G
63

URL itu sendiri dienkripsi, sehingga parameter dalam string kueri tidak berjalan dengan jelas di seluruh kabel.

Namun, perlu diingat bahwa URL termasuk data GET sering dicatat oleh server web, sedangkan data POST jarang. Jadi jika Anda berencana untuk melakukan sesuatu seperti /login/?username=john&password=doe, maka jangan; gunakan POST sebagai gantinya.

— Thomas
sumber
2
+1 terima kasih. Ini di server fisik saya sendiri, jadi saya tidak terlalu khawatir tentang log, tapi itu pertimbangan yang baik bagi siapa pun yang mempertimbangkan ini di lingkungan hosting bersama. Ini juga penting untuk dipertimbangkan karena saya akan mentransfer nomor kartu kredit dengan cara ini, dan pasti tidak ingin mencatatnya :)
— orokusaki
3
Tidak masalah kalau itu kotak Anda sendiri. Anda tidak ingin orang lain yang memilikinya (yaitu peretas jahat) melihat kata sandi tersebut dalam teks biasa. Atau nomor-nomor CC tersebut (dengan asumsi Anda juga tidak menyimpannya di tempat lain).
— Thomas
1
Anda harus meletakkan ini di badan POST, bukan string kueri URL.
— Thomas
1
Apakah Anda khawatir wbeserver memiliki pembatasan lebih sedikit pada akses ke log daripada pada akses ke data situs web (DB, file, dll.)? IMHO selama data dengan aman mengakses server web, semuanya baik-baik saja. satu-satunya orang yang memiliki akses ke server web harus dianggap andal karena jika tidak, Anda tidak akan mencegah mereka membaca data dengan cara apa pun.
— Serge Profafilecebook
1
Ketika kata sandi dikirim melalui GET dan kata sandi tersebut dimasukkan dalam log akses, kata itu TIDAK di- hash. Saya percaya itu adalah masalah terbesar. Memiliki kata sandi hash dalam database tidak masalah jika Anda bisa mencarinya di log akses server web. Mereka harus di-hash dalam database, jika tidak, tolong perbaiki.
— Steen Schütt
21

HTTPS Membuat koneksi SSL yang mendasari sebelum data HTTP apa pun ditransfer. Ini memastikan bahwa semua data URL (dengan pengecualian hostname, yang digunakan untuk membangun koneksi) dilakukan sepenuhnya dalam koneksi terenkripsi ini dan dilindungi dari serangan man-in-the-middle dengan cara yang sama dengan data HTTPS.

Di atas adalah bagian dari jawaban SANGAT komprehensif dari Google Answers yang terletak di sini:

http://answers.google.com/answers/threadview/id/758002.html#answer

— DVK
sumber
6

Semuanya dienkripsi, tetapi Anda harus ingat, bahwa kueri Anda akan tetap di log server dan akan dapat diakses oleh berbagai penganalisa log dll (yang biasanya tidak terjadi dengan permintaan POST).

— Callback Eugene Mayevski
sumber
1
server yang mana? dapat diakses oleh siapa?
— Jader Dias
2
@ Jader ke admin server itu setidaknya dan untuk peretas. Dengan permintaan POST informasi tidak tetap di log jadi kecuali jika itu dicatat secara eksplisit, tidak ada masalah dengan log. GET kueri tetap tersimpan dalam log dan jika apa pun yang terjadi dengan log (atau admin memutuskan untuk menggunakan log ini untuk aktivitas buruk), Anda dalam masalah.
— Eugene Mayevski 'Callback
4

Koneksi akan dienkripsi sebelum permintaan dikirimkan. Jadi ya, permintaan juga dienkripsi, termasuk string kueri.

— cao
sumber
4

Ya, aman. SSL mengenkripsi semuanya.

Kutipan dari permintaan POST:

POST /foo HTTP/1.1
... some other headers

Kutipan dari permintaan GET:

GET /foo?a=b HTTP/1.1
... some other headers

Dalam kedua kasus, apa pun yang dikirim pada soket dienkripsi. Fakta bahwa klien melihat parameter di browsernya selama permintaan GET tidak berarti bahwa seorang pria di tengah akan melihat hal yang sama.

— Darin Dimitrov
sumber
4

Saya baru saja terhubung melalui HTTPS ke situs web dan melewati banyak parameter GET. Saya kemudian menggunakan wireshark untuk mengendus jaringan. Menggunakan HTTP, URL dikirim tidak terenkripsi, yang berarti saya dapat dengan mudah melihat semua parameter GET di URL. Menggunakan HTTPS, semuanya dienkripsi dan saya bahkan tidak bisa melihat paket mana yang merupakan perintah GET, apalagi isinya!

— Jeff Lamb
sumber
3

SSL terjadi sebelum penguraian header, ini berarti:

Client creates Request
Request gets encrypted
Encrypted request gets transmitted to the Server
Server decrypts the Request
Request gets parsed

Permintaan terlihat seperti ini (tidak dapat mengingat sintaks yang tepat, tetapi ini harus cukup dekat):

GET /search?q=qwerty HTTP/1.1
Host: www.google.de

Ini juga mengapa memiliki Sertifikat SSL yang berbeda untuk beberapa host pada IP yang sama bermasalah, Hostname yang diminta tidak diketahui sampai dekripsi.

— Morfildur
sumber
1
Itu HTTP/1.1datang di akhir baris pertama.
— Marcelo Cantos
@Marcelos Cantos: Terima kasih, sudah agak lama sejak saya harus menulis Permintaan HTTP dengan Tangan.
— Morfildur
0

Permintaan GET dienkripsi saat menggunakan HTTPS - sebenarnya inilah sebabnya situs web yang diamankan harus memiliki alamat IP yang unik - tidak ada cara untuk mendapatkan nama host yang dimaksud (atau direktori virtual) dari permintaan sampai setelah didekripsi.

— Michael Burr
sumber
JFYI: Ada ekstensi TLS yang memungkinkan klien menentukan nama host dan server dapat memilih sertifikat yang sesuai.
— Eugene Mayevski 'Callback
@Eugene: Terima kasih - Saya mengetahui ekstensi TLS, tetapi hanya dalam kesadaran yang paling longgar - Saya tidak tahu detail atau seberapa luas mungkin (atau mungkin tidak) dalam penggunaan aktual.
— Michael Burr
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.