Bisakah saya menggunakan Pin Kunci Publik dengan LetsEncrypt?

10

Bisakah saya mengatur Pin-Kunci-Publik ketika saya mengatur cronjob untuk memperbarui sertifikat LetsEncrypt setiap 30 hari?

Jika sertifikat diperpanjang maka Public-Key-Pin juga diperpanjang bukan?

ssl  ssl-certificate  tls  http-headers  public-key 
— Bob Ortiz
sumber

Jawaban:

12

Beberapa kata hati-hati untuk memulai dengan:

  • Ketahuilah apa yang Anda lakukan, jika Anda berencana untuk menerapkan HPKP.
  • Jika Anda tidak melakukannya dengan benar, atau "jika hal-hal buruk terjadi", yang tidak berada di bawah kendali Anda, Anda mungkin membuat domain Anda tidak dapat digunakan.
  • Pastikan untuk menguji pengaturan Anda dengan domain yang tidak terlalu penting, atau dengan waktu cache yang sangat singkat, misalnya sepuluh detik.
  • Pikirkan sertifikat mana yang ingin Anda pin: Root, intermediate, leaf ...
  • Pikirkan jika masuk akal untuk menyematkan otoritas sertifikat (cadangan) lain, itu adalah sertifikat perantara dan sertifikat daun Anda.
  • Lebih baik aman daripada menyesal: Pikirkan jika masuk akal untuk menyematkan CA / cert cadangan lain, untuk memiliki dua.
  • Jika poin dan pertanyaan ini terdengar "baru" bagi Anda: Baca tentang HPKP tentang apa dan perangkap umum dan peringatan, sebelum Anda menerapkan ini.

Bisakah saya menggunakan Pin Kunci Publik dengan LetsEncrypt?

  • Iya.

Jika sertifikat diperpanjang maka Public-Key-Pin juga diperpanjang bukan?

  • Ini tergantung pada sertifikat mana yang Anda maksud dan sertifikat mana yang Anda pin.
— gf_
sumber
9

Akan mengulangi semua yang dikatakan gf_.

Namun, untuk menjawab pertanyaan, ya Anda bisa.

Secara default Let's Encrypt membuat ulang kunci dan sertifikat saat pembaruan. Ini membuat penerapan HPKP sulit jika Anda ingin menyematkan daun, yang mungkin harus Anda lakukan jika terjadi perubahan sedang ( seperti yang terjadi pada Maret 2016 ).

Jadi Anda memiliki beberapa opsi untuk ini jika Anda masih ingin melakukan HPKP:

  1. Gunakan CSR tetap Anda sendiri daripada klien standar yang menciptakan CSR untuk Anda setiap kali sehingga kunci daun tidak berubah. Posting blog ini menjelaskan cara melakukan ini secara khusus karena penulis menggunakan HPKP.
  2. Gunakan kadaluarsa singkat HPKP dan perbarui dalam waktu kadaluwarsa itu dan ubah kebijakan untuk memiliki kunci lama dan baru sebelum benar-benar mengubah sertifikat, dengan cukup waktu bagi kebijakan baru untuk diambil oleh pengunjung mana pun.
  3. Sematkan akar Let's Encrypt sebagai ganti daun atau sertifikat.
— Barry Pollard
sumber
1
Tambahan yang bagus, +1.
— gf_
Apakah aman untuk menyematkan root? Untuk MITM, sangat mudah menggunakan sertifikat Let's Encrypt-nya sendiri.
— melbic
2
Bagaimana "sangat mudah" bagi penyerang untuk mendapatkan sertifikat untuk nama domain Anda menggunakan Let's Encrypt? Tidak mengetahui cara melakukan hal itu. Namun mungkin menjadi mungkin dengan setiap CA jika mereka memiliki bug dalam prosedur validasi domain mereka. Dengan menyematkan root LE Anda secara besar-besaran mengurangi permukaan serangan Anda menjadi Let's Encrypt sebagai lawan dari setiap CA di dunia. Masih tidak seaman pinning leaf, saya setuju tapi itu memperkenalkan risiko sendiri jadi tergantung pada definisi Anda "aman".
— Barry Pollard
Mengatakan bahwa saya pikir ada risiko BESAR terhadap HPKP - kebanyakan dari perspektif bunuh diri - jadi saya bukan penggemar. Jika Anda memutuskan untuk mengubah CA, atau perubahan jalur sertifikat (misalnya karena depresiasi SHA-256), atau harus segera menerbitkan ulang sertifikat, atau kunci cadangan dikompromikan / hilang atau orang yang mengaturnya pergi dan orang berikutnya tidak menyadari mereka menggunakan HPKP dan / atau tidak mengetahuinya. HPKP juga tidak melindungi terhadap akar lokal seperti Superfish. Jadi, untuk sebagian besar situs, HPKP, terlalu rumit dan, IMHO, tidak sepadan dengan perlindungan tambahan untuk sedikit tambahan keamanan. Tapi itu hanya pendapat saya.
— Barry Pollard
Ok, saya hanya bertanya karena saya pikir, bahwa semua sertifikat LE memiliki sertifikat root yang sama. Jadi, jika Anda menyematkan orang lain dengan sertifikat LE lain hanya dapat menggunakan MITM dan palsu di sertifikat itu sendiri. Apa kamu tau maksud saya?
— melbic
5

Saya baru saja mengimplementasikan ini menggunakan klien dehidrasi dengan validasi dns01. Hook dns01 pasti karena DNS kami dihosting di Azure.

Sunting: ketika saya berbicara tentang kunci pribadi, jelas saya selalu berarti bahwa Anda hanya mengubah bagian-bagian kunci publik menjadi pin. Kunci pribadi, seperti namanya, harus selalu tetap pribadi. Lihat kait saya sendiri untuk detail implementasi.

Anda perlu rollover kunci pribadi untuk memungkinkan ini. Artinya, Anda selalu memiliki kunci privat saat ini (sebut saja A) dan kunci privat yang akan datang (sebutlah B), sehingga Anda dapat menambahkan keduanya ke pin Anda. Jadi pada titik ini pin Anda adalah A dan B. Ketika hari pembaruan cert datang, kunci pribadi A menjadi usang dan B menjadi hidup. Pada saat yang sama Anda mendapatkan kunci privat masa depan yang baru, sebut saja C. Anda membuat ulang daftar pin Anda sehingga sekarang mengandung B dan C. Jadi itulah cara Anda menggulirkan kunci pribadi Anda. dehidrasi mendukung ini sekarang .

Selain itu, Anda memerlukan pengait yang disebut setiap kali Anda memperbarui sertifikat dan dengan demikian menggulingkan kunci pribadi Anda. Saya menerapkan ini sendiri .

Akhirnya, jika saya melakukan ini dengan benar, Anda harus memastikan bahwa:

HPKP age x 2 < days between cert renewals

Misalnya, jika usia HPKP Anda adalah 50 hari dan Anda memperbarui sertifikat setiap 30 hari, klien yang mengunjungi situs Anda pada hari pertama akan terjebak dengan kunci pribadi A dan B, dan Anda berguling ke B dan C pada hari ke-31. server memiliki B dan C, klien memiliki A dan B, ada kecocokan bahkan pada hari ke-50 dan klien membuka situs dengan benar.

TAPI mari kita lihat apakah usia HPKP adalah 70 hari. Anda memperbarui sertifikat setiap 30 hari, dan klien mengunjungi situs Anda pada hari pertama, jadi sekali lagi, itu hanya memiliki kunci pribadi A dan B. Anda berguling ke B dan C pada hari 31, dan berguling ke C dan D pada hari ke-61 Server Anda memiliki C dan D, klien memiliki A dan B, tidak ada kecocokan dan klien diberikan jari tengah dari hari 61 hingga hari 71, ketika kebijakan HPKP-nya berakhir.

Pilihan lain, mungkin lebih aman, dan tentu saja jauh lebih sederhana adalah menggunakan kunci privat yang sama setiap kali dan menghasilkan satu atau beberapa kunci privat cadangan, kemudian meng-hardcoding ini ke dalam konfigurasi HPKP Anda dan selesai dengan itu.

Ya, itu rumit dan mungkin ada peringatan yang belum saya pikirkan, tapi kita akan lihat dalam jangka panjang. Jelas saya menyebarkannya di subdomain tidak kritis dengan umur HPKP pendek (15 hari) sehingga tidak menyebabkan masalah besar.

Sunting: Saya telah menulis beberapa skrip untuk membantu Anda mengatur HPKP dengan Let's Encrypt dan dehidrasi menggunakan Nginx:

HPKPinx

— bviktor
sumber
3
Saya memutuskan untuk memiliki yang terbaik dari kedua dunia. Rollover kunci pribadi otomatis + kunci privat statis. Mungkin menulis posting blog tentang hal itu jika ada yang tertarik.
— bviktor
1
Jika Anda melakukan ini, silakan edit posting Anda dan masukkan tautan - terima kasih!
— gf_
Terima kasih, saya akan mencoba yang terbaik untuk menyelesaikan ini atau minggu depan
— bviktor
2
Tautan ditambahkan. Dokumentasi masih langka, tetapi kodenya ada sehingga Anda dapat mencobanya dan meretasnya.
— bviktor
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.