SIP TLS

Ringkasan:

1. Freeswitch membutuhkan agen.file PEM dengan izin yang benar untuk bertindak sebagai server TLS.

2. Transport Layer Security (TLS) adalah protokol yang digunakan untuk melindungi pesan SIP agar tidak dicegat.

3. TLS adalah evolusi protokol SSL sebelumnya yang digunakan untuk enkripsi web.

4. Sertifikat dan kriptografi asimetris adalah komponen utama TLS.

5. Sertifikat digunakan untuk mengotentikasi entitas, dan otoritas sertifikat memverifikasi keasliannya.

6. Kriptografi simetris dan asimetris digunakan untuk enkripsi dan dekripsi data.

7. TLS menggunakan kriptografi simetris untuk otentikasi dan kriptografi asimetris untuk mengenkripsi data curah.

8. TLS dapat digunakan untuk secara aman membuat percakapan SIP melalui internet yang tidak aman.

9. Freeswitch mendukung pensinyalan terenkripsi (SIP) dengan sertifikat yang ditandatangani dan Audio/Media Terenkripsi (SRTP).

10. Freeswitch memungkinkan konfigurasi port untuk SIP di dalam profil SIP.

Pertanyaan:

1. File apa yang dibutuhkan Freeswitch untuk bertindak sebagai server TLS?

Menjawab: Freeswitch membutuhkan agen.file PEM.

2. Mengapa penting untuk memiliki izin yang benar untuk agen.PEM?

Menjawab: Izin yang salah dapat mencegah pendengar TLS berfungsi dengan baik.

3. Untuk apa TLS digunakan di SIP?

Menjawab: TLS digunakan untuk melindungi pesan SIP agar tidak dicegat.

4. Apa perbedaan antara TLS dan SSL?

Menjawab: TLS adalah evolusi SSL dan digunakan untuk protokol web dan real-time seperti SIP.

5. Untuk apa sertifikat digunakan dalam tls?

Menjawab: Sertifikat digunakan untuk mengotentikasi entitas.

6. Apa tujuan otoritas sertifikat?

Menjawab: Otoritas sertifikat memverifikasi keaslian sertifikat.

7. Apa dua jenis kriptografi yang digunakan dalam TLS?

Menjawab: Kriptografi simetris dan asimetris.

8. Bagaimana cara kerja kriptografi simetris?

Menjawab: Data dienkripsi dan didekripsi menggunakan kunci yang sama.

9. Bagaimana cara kerja kriptografi asimetris?

Menjawab: Data dienkripsi dan didekripsi menggunakan kunci publik dan kunci pribadi.

10. Untuk apa TLS menggunakan kriptografi simetris?

Menjawab: TLS menggunakan kriptografi simetris untuk otentikasi.

11. Untuk apa TLS menggunakan kriptografi asimetris?

Menjawab: TLS menggunakan kriptografi asimetris untuk mengenkripsi data curah.

12. Dapatkah TLS digunakan untuk membuat percakapan SIP yang aman melalui internet yang tidak aman?

Menjawab: Ya, TLS dapat digunakan untuk percakapan SIP yang aman melalui internet yang tidak aman.

13. Apa yang Dukungan Freeswitch dalam hal pensinyalan terenkripsi?

Menjawab: Freeswitch mendukung pensinyalan terenkripsi yang dikenal sebagai SIP.

14. Apa port default untuk SIP?

Menjawab: Port default untuk SIP adalah port TCP 5061.

15. Apa yang dapat dikonfigurasi dalam profil SIP di Freeswitch?

Menjawab: Port untuk SIP dapat dikonfigurasi dalam profil SIP di Freeswitch.

SIP TLS

Freeswitch hanya membutuhkan satu file untuk bertindak sebagai server TLS dan itulah agennya.file PEM. Ini berisi sertifikat dan kunci yang akan digunakan untuk mendengarkan. Perhatikan sangat penting bahwa agen Anda.PEM (dan opsional Cacert.PEM) memiliki izin membaca untuk pengguna freeswitch akan berjalan sebagai. Itu berarti jika Anda menggunakan -u freeswitch Anda ingin “agen chmod 640.PEM CACERT.PEM “dan” Chown Root.Agen Freeswitch.PEM CACERT.PEM “. Izin yang salah tidak akan memungkinkan pendengar TLS untuk berputar dengan benar. Di vars Anda.xml:

Memahami Transport Layer Security (TLS)

Selama beberapa artikel blog i’ve menyebutkan beberapa aspek keamanan SIP. Dalam membuktikannya dengan otentikasi SIP, saya membahas penggunaan pesan respons dan header otentikasi. Keamanan semacam itu disampaikan di tingkat protokol. Dengan kata lain, klien SIP dan server bertukar pesan yang menegakkan keamanan tingkat identitas. Tentu saja, karena SIP itu sendiri adalah protokol berbasis teks kami membutuhkan sesuatu yang melindungi pesan dan kontennya dari mata yang mengintip. Memasuki Keamanan Lapisan Transportasi (Tls).

TLS adalah evolusi protokol sebelumnya yang disebut Lapisan Soket Aman (SSL). SSL dikembangkan beberapa tahun yang lalu oleh Netscape (ingat Netscape?) dan digunakan untuk mengenkripsi data yang dikirim antara browser web dan server web. Anda tahu bahwa Anda menggunakan SSL ketika baris alamat browser Anda terkandung “https” dan tidak “http.” Beberapa browser juga akan menampilkan simbol kunci saat SSL sedang digunakan.

Seperti kebanyakan protokol lain yang digunakan oleh SIP, TLS dikendalikan oleh Gugus Tugas Rekayasa Internet (IETF). Pada awalnya, TLS dan SSL Weren’t semua berbeda satu sama lain. Namun, karena definisi aslinya pada tahun 1999, TLS terus berkembang menjadi protokol transportasi yang sangat aman untuk protokol web dan real-time seperti SIP.

Inti dari TLS adalah sertifikat dan konsep simetris Dan Kriptografi asimetris. Saya bisa menulis ribuan kata tentang ketiganya, tetapi Anda bisa belajar cukup untuk menjadi berbahaya hanya dalam beberapa paragraf.

Pertama, sertifikat adalah bentuk ID digital yang digunakan entitas untuk mengidentifikasi dirinya sendiri. Anggap saja sebagai pengemudi’S lisensi untuk komponen IP. Namun, untuk mencegah orang jahat menempa pengemudi itu’S lisensi, Otoritas Sertifikat (Ca) ada yang digunakan untuk memvalidasi keaslian sertifikat. Ada CA pribadi yang dioperasikan oleh perusahaan. Ada juga CA publik yang tersedia melalui internet. Verisign adalah contoh dari CA publik yang terkenal.

Berikutnya adalah kriptografi simetris dan asimetris. Keduanya berkaitan dengan bagaimana data dienkripsi dan tidak terenkripsi. Dalam kasus kriptografi simetris, data dienkripsi dengan kunci. Dia’s juga tidak terenkripsi dengan kunci yang sama. Jadi, jika dua entitas yang berbeda memiliki kunci itu, mereka dapat mengirim data terenkripsi bolak -balik dan tidak ada orang tanpa kunci yang akan memahami apa yang mereka katakan. Kekuatan kriptografi simetris adalah bahwa ia cepat dan menggunakan daya pemrosesan dalam jumlah minimal. Kelemahannya adalah Anda membutuhkan mekanisme yang aman untuk menukar kunci.

Data juga dienkripsi dengan kriptografi asimetris, tetapi dalam hal ini ada dua kunci – kunci publik dan pribadi. Kunci publik biasanya terkandung dalam sertifikat entitas IP dan siapa pun dengan sertifikat itu akan memiliki kunci publik. Kunci pribadi dirahasiakan dan tidak pernah terungkap kepada siapa pun. Dua kunci ini bekerja sama untuk mengenkripsi dan mendekripsi data yang dikirim pada koneksi IP.

Data yang dienkripsi dengan kunci publik hanya dapat dienkripsi dengan kunci pribadi terkait. Data yang dienkripsi dengan kunci pribadi hanya dapat dienkripsi dengan kunci publik yang cocok. Bentuk enkripsi ini dikenal sebagai Kriptografi kunci publik. Itu membutuhkan lebih banyak daya pemrosesan daripada kriptografi simetris, tetapi menciptakan tautan data yang aman yang hanya klien dan server yang dapat menguraikan.

Saya menulis bahwa TLS menggunakan kriptografi simetris dan asimetris. Ini menggunakan simetris untuk otentikasi dan asimetris untuk enkripsi data curah. Dalam kasus kami, data curah itu adalah pesan dan tanggapan SIP. Perhatikan bahwa data ini tidak termasuk aliran media yang sebenarnya seperti g.711 atau g.729. Data itu dienkripsi menggunakan Mengamankan protokol real-time (SRTP) – Sebuah blog untuk hari lain.

Jika Anda masih membaca, saya memuji keuletan Anda. Ini bukan hal yang mudah untuk dimengerti. Perlu diingat hal -hal berikut, dan Anda akan baik -baik saja. Sertifikat digunakan untuk memverifikasi keaslian klien dan server. Otoritas sertifikat ada untuk memverifikasi bahwa sertifikat tidak dipalsukan. Kunci publik dan pribadi digunakan untuk mengenkripsi pesan yang dipertukarkan antara entitas SIP. Ini berarti bahwa dengan TLS Anda dapat dengan aman menggunakan internet yang tidak aman untuk membuat percakapan SIP yang aman. Bahkan jika pesan SIP Anda dicegat, mereka menang’T Apakah ada orang baik karena mereka tidak akan dapat memahami apa yang dikatakan.

SIP TLS

Freeswitch mendukung kedua pensinyalan terenkripsi yang dikenal sebagai SIP yang dapat SSL atau TLS dengan sertifikat yang ditandatangani, serta audio/media terenkripsi yang dikenal sebagai SRTP. Konvensi yang khas adalah memiliki saluran kontrol SIP yang tidak terenkripsi pada port UDP 5060 (meskipun standar juga memungkinkan untuk menggunakan port TCP 5060 juga), dan saluran kontrol SIP yang dienkripsi atau TLS TLS yang dikenal sebagai SIP pada TCP Port 5061 . Ilustrasi di bawah ini menggambarkan SIP berada di port 5060, dan menyesap sebagai port 5061 dan port (x). Freeswitch memungkinkan Anda untuk mengkonfigurasi port ini di dalam profil SIP.

Data RTP menggunakan UDP, tetapi port yang digunakan RTP dinamis karena dinegosiasikan dalam saluran kontrol SIP. Freeswitch dapat dikonfigurasi untuk menggunakan rentang port tertentu untuk aliran RTP. Di bagian 1 dari halaman ini kami akan membahas anatomi koneksi SIP dan kemungkinan konfigurasi sehingga Anda dapat memilih konfigurasi mana yang paling sesuai dengan skenario Anda dan mengkonfigurasi sistem freeswitch Anda sesuai.

Anatomi koneksi SIP

Pertama, mari kita tinjau anatomi koneksi SIP untuk menghilangkan kebingungan yang mungkin timbul dari asumsi bahwa enkripsi menyiratkan bahwa aliran audio (atau RTP) dienkripsi.

Pada Gambar 1 Anda akan mencatat bahwa memang ada tiga koneksi terpisah, satu TCP untuk kontrol, dan dua lainnya adalah UDP untuk melewati aliran audio ke dan dari sakelar. Saluran Kontrol memfasilitasi sejumlah kemampuan, tetapi sehubungan dengan enkripsi yang terutama kami perhatikan adalah digit DTMF yang diputar selama panggilan, seperti pin bank, atau semacam kode akses lainnya yang bersifat pribadi dan, yang paling penting, informasi pribadi. Dengan skenario yang digambarkan pada Gambar 1, siapa pun di jaringan dapat mengendus dan memecahkan kode data yang berharga ini.

Anatomi koneksi SIPS

Jawaban untuk masalah ini digambarkan pada Gambar 2 dan untuk mengenkripsi saluran SIP dengan pembungkus SSL atau TLS sehingga siapa pun mengendus paket pada kawat tidak dapat mendekripsi data di saluran kontrol. Anda akan mencatat bahwa pada Gambar 2 kami menggambarkan ini seperti pada port 5061, tetapi dengan freeswitch Anda sebenarnya dapat mengkonfigurasinya untuk berada di port tertentu yang Anda inginkan. Skenario ini di sini masih meninggalkan paket untuk data audio di benak. Seseorang mengendus paket akan dapat merekonstruksi percakapan Anda yang terdengar dan “mendengarkan” tanpa banyak kesulitan.

* Catatan: Ponsel IP dapat mengiklankan mereka mendukung enkripsi, tetapi Anda mungkin ingin memeriksa spesifikasi untuk memvalidasi mereka mendukung sertifikat yang ditandatangani oleh SSL dan TLS.

Anatomi koneksi SIPS dan SRTP

Pada Gambar 3 Anda akan mencatat bahwa tidak hanya saluran kontrol yang dienkripsi, tetapi aliran RTP juga dienkripsi dan dikirim sebagai SRTP. Dengan cara ini, dan hanya dengan cara ini, seluruh percakapan Anda cukup aman dari menguping. Ini juga penting karena digit DTMF juga dapat dikirim dalam data RTP juga (inband). Memiliki enkripsi SIP dan SRTP adalah pilihan terbaik Anda saat memastikan panggilan SIP Anda aman.

* Catatan: Ponsel IP dapat mengiklankan mereka mendukung enkripsi, Anda perlu memeriksa spesifikasi ponsel untuk menentukan apakah itu mendukung SRTP. Lebih banyak yang akan dikatakan tentang ini di bawah ini bersama dengan masalah interoperabilitas dengan ponsel tertentu di bagian bawah halaman ini.

Kemampuan enkripsi freeswitch

Halaman ini hanya akan mencakup enkripsi TLS, SSL dan SRTP.

Enkripsi TLS, SSL dan SRTP

Freeswitch mendukung SIP melalui SSL dan/atau TLS, bersama dengan kemampuan enkripsi SRTP. Tidak jelas apakah Freeswitch akan mengenkripsi aliran video karena ini belum diuji di lab KJV, namun saya curiga itu akan. Jika Anda melakukan pengujian yang mengenkripsi video SRTP, dengan segala cara tambahkan hasil Anda ke wiki.

Enkripsi ZRTP ZRTP sekarang didepreicated dan akan dihapus dari dokumen​

ZRTP adalah kemampuan enkripsi oportunistik yang dapat dikompilasi menjadi freeswitch. Lihat halaman ZRTP untuk Informasi How-To dan tambahan yang berkaitan dengan ZRTP.

Enkripsi hibrida

Faktanya Faktanya dapat mengenkripsi data untuk lalu lintas SIP yang melewatinya. Dengan cara ini Anda dapat memberikan enkripsi untuk telepon IP yang tidak secara asli mendukung enkripsi. Karena ada sejumlah besar perangkat keras SIP yang tidak mendukung enkripsi, konfigurasi ini mungkin terbukti bermanfaat untuk sejumlah situasi praktis.

Pada Gambar 4 Anda akan melihat bahwa saluran kontrol SIP dari ponsel ke sakelar tidak dienkripsi sedangkan saluran kontrol dari Freeswitch ke SIP PBX lainnya dienkripsi. Penting untuk dipahami bahwa dalam situasi ini Kontrol SIP dan data RTP (audio) keduanya tidak terenkripsi antara telepon IP dan Freeswitch. Oleh karena itu, jika ponsel IP SIP Anda ada di suatu tempat di belakang router NAT pada modem kabel, dan FreeSwitch tidak ada di belakang router ini, baik LAN ponsel dan koneksi internet ke FreeSwitch sepenuhnya di tempat terbuka, yang berarti bahwa seseorang dapat mengendus paket -paket itu dan mendapatkan informasi yang berharga.

Selain itu, data RTP (audio) antara Freeswitch dan titik akhir jarak jauh diilustrasikan sebagai “SIP PBX lainnya” juga tidak terenkripsi dan dapat dicegat, namun saluran kontrol untuk koneksi ini dienkripsi dan karenanya cukup aman secara wajar. Jika Freeswitch berada di LAN yang sama dengan telepon, kemungkinan intersepsi lebih sedikit, tetapi data audio masih mampu dicegat.

Pada Gambar 5 Anda akan melihat bahwa data SIP dan RTP dari ponsel IP tidak terenkripsi, sedangkan data SIP dan RTP ke PBX SIP lainnya adalah SIP dan SRTP yang dienkripsi. Opsi ini akan mengenkripsi saluran kontrol dan data audio untuk koneksi antara FreeSwitch dan titik akhir lainnya yang mendukung enkripsi.

Masih perlu dipahami bahwa koneksi dari telepon ke Freeswitch sepenuhnya mampu dicegat oleh paket sniffer.

Memilih antara opsi enkripsi

Ada berbagai pilihan enkripsi untuk Freeswitch seperti dijelaskan di atas. TLSV1 mengenkripsi semuanya di atas koneksi TCP; Ini memiliki downside bahwa jitter atau penundaan karena TCP dapat terjadi. UDP umumnya lebih disukai untuk RTP dan menggunakan TLSV1 memiliki beberapa overhead lalu lintas tambahan. Akhirnya ada SSLV23; Ini mengenkripsi saluran kontrol SIP melalui koneksi TCP terenkripsi menggunakan sertifikat SSL, tetapi secara default tidak menyediakan apa pun untuk data RTP. Informasi login dan metadata panggilan ditransmisikan melalui saluran kontrol jadi jika ini adalah apa yang Anda pedulikan untuk melindungi ini sudah cukup dan dan tidak menambahkan overhead ke data RTP. Jika Anda ingin mengenkripsi data suara itu sendiri (jadi data suara tidak dapat dipahami), itu dapat dikombinasikan dengan SRTP. SRTP memungkinkan enkripsi data RTP dengan overhead kecil untuk masing -masing paket RTP UDP. Ini memiliki manfaat bahwa data panggilan dienkripsi tetapi masih lebih dari UDP sehingga seharusnya tidak ada perbedaan dengan SRTP ON seperti halnya dengan itu. Kunci enkripsi yang digunakan untuk SRTP dipertukarkan melalui saluran kontrol (yang dienkripsi SSLV23) jadi memberi Anda sesuatu yang terbaik dari kedua dunia. Umumnya SSLV23 + SRTP adalah yang paling ramah firewall/memiliki perubahan paling sedikit untuk instalasi yang ada. SSLV23 + SRTP juga cukup mudah dikonfigurasi di server Freeswitch dan kemungkinan besar metode enkripsi yang paling didukung untuk sebagian besar klien dan ponsel SIP sehingga umumnya harus di mana seseorang harus mulai untuk mengenkripsi data panggilan.

Tentang ponsel dan enkripsi IP

Beberapa vendor akan mengiklankan bahwa produk mereka mendukung enkripsi SIP. Pertanyaannya menjadi seberapa baik mendukung enkripsi SIP. Jadi mari kita tinjau teka -teki pemasaran yang berbelit -belit ini.

• Ponsel ini dapat mendukung SIP terenkripsi SSL dan/atau TLS, yang berarti “SIP”.
• Telepon mungkin melangkah lebih jauh untuk mendukung TLS dengan sertifikat yang ditandatangani.
• Di atas dan di luar peringatan itu, telepon mungkin melangkah lebih jauh untuk mendukung data audio terenkripsi SRTP.
• Terakhir, pastikan ponsel IP mendukung standar SIP dan/atau enkripsi SRTP. Pada dasarnya tidak terlalu jauh untuk produsen untuk menghasilkan metode enkripsi berotak rambut yang hanya bekerja dengan produk mereka.

PERINGATAN: Periksa spesifikasinya dan lakukan riset Anda sebelum membeli ponsel IP SIP yang mengiklankan dirinya sebagai mampu melakukan enkripsi. Anda mungkin juga ingin memeriksa apakah ada masalah dengan versi firmware SIP yang sedang dijalankan ponsel Anda dan interoperabilitasnya dengan Freeswitch.

Keterbatasan Implementasi Freeswitch TLS/SSLV23 (FS-3877)

Sayangnya lib default _ stack sofia dan konfigurasi freeswitch memiliki satu perilaku default (mungkin tidak terduga) yang dapat menyebabkan masalah enkripsi yang sulit didiagnosis. Saat klien terhubung ke server, ia membuat saluran TCP terenkripsi yang digunakan untuk berkomunikasi dengan server. Kapan saja melakukan panggilan, register, dll., itu melakukannya dengan menggunakan sesi TCP ini. Sayangnya, ketika FreeSwitch berupaya berkomunikasi dengan klien untuk menceritakannya tentang panggilan yang masuk, pemberitahuan, dll., itu membuat saluran TCP kedua dari server ke klien. Sementara ini dienkripsi, ini dapat menyebabkan beberapa masalah untuk beberapa konfigurasi firewall dan untuk banyak opsi keamanan TLS/SSL di FreeSwitch. Jika Freeswitch tidak dapat menetapkan saluran ini, klien akan dapat melakukan panggilan tetapi tidak akan dapat menerima panggilan (atau apa pun yang berasal dari server ke klien). Selain itu, banyak fitur TLS dapat bertindak secara tak terduga, jadi arahnya penting untuk dipertimbangkan. Misalnya, TLS-Verify-Policy Set ke “Out” akan menyebabkan FreeSwitch mencoba memverifikasi sertifikat klien ketika menghubungkan kembali ke klien, jadi meskipun klien terhubung ke server pada awalnya dan itu akan melewatkan validasi untuk panggilan dari server- klien, Freeswitch akan memverifikasinya. Selain itu, ini dapat membuka lubang keamanan, misalnya menetapkan kebijakan untuk “dalam” untuk verifikasi klien yang masuk tidak akan memverifikasi sertifikat klien ketika server terhubung kembali ke klien, yang akan memungkinkan serangan MITM terjadi di sana. Hal -hal seperti validasi subjek juga bisa rumit, terutama jika FreeSwitch bertindak sebagai klien. Misalnya, validasi subjek memeriksa nama host yang FreeSwitch terhubung dengan nama umum sertifikat, sementara pemeriksaan keamanan yang bagus tidak mungkin dilakukan ketika server terhubung kembali ke Freeswitch (seperti pada saat itu Freeswitch sebenarnya mencoba untuk memeriksa alamat IP dengan nama umum). Selain itu, validasi tujuan (memastikan kapan Freeswitch menghubungkan ke server itu sertifikat yang telah dikeluarkan untuk server dan bukan klien, atau sebaliknya) saat ini tidak didukung. Ini memungkinkan serangan MITM terhadap server FreeSwitch menggunakan sertifikat klien (atau sebaliknya), tetapi karena koneksi berjalan dua arah, validasi tujuan saat ini tidak didukung (karena koneksi yang masuk mungkin dari sertifikat server saat menghubungkan kembali). Jadi sementara Freeswitch’s Gentls _ Cert tidak menetapkan dengan benar tujuan yang saat ini tidak digunakan oleh Freeswitch sendiri. Salah satu solusi untuk menghindari lubang mitm ini adalah mengeluarkan sertifikat klien dari CA yang berbeda untuk saat ini.

Konfigurasi

Freeswitch mendukung enkripsi lalu lintas pensinyalan SIP melalui SSL dan/atau TLS. Konvensi ini adalah menjalankan SIP di port 5061 . Konfigurasi yang lebih kompleks dimungkinkan, namun mereka tidak akan dibahas dalam dokumentasi ini.

Anda akan membutuhkan yang berikut untuk mengkompilasi FreeSwitch dengan dukungan enkripsi TLS:

• Paket Libssl-Dev (Pengembangan OpenSSL) terpasang.

Jika Anda tidak menginstal paket LIBSSL-DEV, masalahnya adalah profil SIP _ yang berisi arahan konfigurasi enkripsi yang ditentukan di bawah ini pada Langkah 2 akan gagal untuk memulai.

Jika Anda telah menyusun freeswitch tanpa paket ini diinstal, tidak akan ada dukungan untuk enkripsi dan Anda perlu mengkompilasi ulang setelah Anda menginstal paket libssl-dev.

Untuk debian do aptitude install libssl-dev (on lenny install libcurl4-openssl-dev) dan kemudian mengkompilasi.

Langkah 1 – Hasilkan Sertifikat CA (ROOT)

Untuk menggunakan TLS/SSL Anda membutuhkan setidaknya dua sertifikat: sertifikat root (CA) dan sertifikat untuk setiap server. Ada naskah di // freeswitch/bin/gentls _ sertifikat atau di dalam sumber tarball /skrip/gentls _ sertifikat yang membantu menghasilkan file -file ini. Dengan asumsi bahwa nama DNS dari pbx freeswitch Anda adalah pbx.Freeswitch.org, dengan

./gentls_cert setup -cn pbx.Freeswitch.org -alt dns: pbx.Freeswitch.org -org freeswitch.org

Ini akan membuat sertifikat dan kunci CA bersama dengan di direktori dan sertifikat conf/ssl/ca di folder conf/ssl.

[ Catatan: Nama yang diberikan untuk -cn dan -alt harus sama dengan nama DNS dari instalasi FreeSwitch Anda dan digunakan sebagai nama pendaftar di telepon (setidaknya pada polycom). ] Anda dapat mengubah baris “Days = 2190” di file cert gentls _ untuk membuat sertifikat valid untuk waktu yang lebih lama. Namun membuatnya terlalu lama memiliki beberapa masalah pembungkus, tampaknya.

Langkah 2 – Hasilkan Sertifikat Server

./gentls_cert create_server -cn pbx.Freeswitch.org -alt dns: pbx.Freeswitch.org -org freeswitch.org

membuat sertifikat server di // freeswitch/conf/ssl/agen.PEM. File ini berisi sertifikat dan kunci pribadi. Itu harus berisi nama domain dengan nama umum dan alternatif. Jika Anda perlu menghasilkan sertifikat untuk server lain, gunakan flag -out untuk gentls _ sertifikat untuk menentukan sertifikat output/nama file kunci dan salin ini ke server jarak jauh.

Untuk mengatur CA baru dan membuat sertifikat baru di bawah windows, buka di sini.

Agar sertifikat baru berlaku (satu -satunya cara bagi Freeswitch untuk menggunakannya), Freeswitch harus dimasukkan kembali.

Catatan: Nama yang diberikan untuk -cn dan -alt harus sama dengan nama DNS dari instalasi FreeSwitch Anda dan digunakan sebagai nama pendaftar di telepon (setidaknya pada polycom). Ini diperlukan untuk eyebeam (dan mungkin pangolin juga).

Tinjau sertifikat Anda

Anda dapat meninjau detail sertifikat Anda dengan perintah:

OpenSSL X509 -Noout -Inform PEM -Text -in/usr/local/freeswitch/conf/ssl/agen.PEM

Langkah 3 – Konfigurasi Profil Sofia

Freeswitch hanya membutuhkan satu file untuk bertindak sebagai server TLS dan itulah agennya.file PEM. Ini berisi sertifikat dan kunci yang akan digunakan untuk mendengarkan. Perhatikan sangat penting bahwa agen Anda.PEM (dan opsional Cacert.PEM) memiliki izin membaca untuk pengguna freeswitch akan berjalan sebagai. Itu berarti jika Anda menggunakan -u freeswitch Anda ingin “agen chmod 640.PEM CACERT.PEM “dan” Chown Root.Agen Freeswitch.PEM CACERT.PEM “. Izin yang salah tidak akan memungkinkan pendengar TLS untuk berputar dengan benar. Di vars Anda.xml:

Perhatian: TLS dinonaktifkan secara default; Atur internal _ SSL _ Aktifkan dan/atau eksternal _ SSL _ Aktifkan untuk “true” untuk mengaktifkan.

Langkah 4 Konfigurasi Klien

Klien semua harus memiliki setidaknya sertifikat CA Root yang diinstal ke mereka untuk memastikan keamanan. Tanpa mengaktifkan verifikasi rantai (bahwa sertifikat server dikeluarkan oleh CA yang disetujui), serangan MITM dimungkinkan terhadap klien. Sertifikat CA adalah conf/ssl/cafile.PEM hanya berisi sertifikat dan klien yang menggunakannya untuk memastikan sertifikat server dikeluarkan oleh CA. Selain itu, Anda mungkin ingin (atau harus bergantung pada perangkat) menginstal sertifikat klien yang dikeluarkan oleh CA yang sama. Anda dapat menghasilkan sertifikat klien menggunakan perintah:

./gentls_cert create_client -cn client1 -out client1

Ini akan membuat klien1.PEM (perhatikan nama umum di sini tidak terlalu penting, jarang server akan diaktifkan untuk memeriksa subjek sertifikat klien sehingga Anda dapat mengatur ini untuk apa yang Anda inginkan). Pasangan sertifikat/kunci ini harus diinstal pada klien (direkomendasikan berbeda untuk setiap klien untuk keamanan) tetapi tidak perlu tetap di server, bahkan jika Anda ingin server memverifikasi sertifikat klien. Jika klien adalah server freeswitch lain yang klien1.PEM Anda ingin mengganti nama menjadi agen.PEM. CATATAN Jika server FreeSwitch lainnya juga akan menggunakan sertifikat ini sebagai server dan bukan hanya klien pastikan untuk mengikuti langkah -langkah di atas menggunakan perintah Buat _ untuk membuat sertifikat server.

Sertifikat Komersial

Sebagian besar sertifikat server web komersial harus berfungsi untuk freeswitch. Misalnya, sertifikat Thawte SSL123 (opsi termurah mereka) diketahui berfungsi dalam setidaknya satu instalasi. Jika Anda ragu tentang apakah sertifikat akan berfungsi, Anda hanya boleh membeli sertifikat dari perusahaan yang menawarkan kebijakan pengembalian dana 30 hari.

Beberapa profil TLS

Jika Anda memiliki beberapa profil Sofia SIP, Anda mungkin ingin mengaktifkan dukungan TLS untuk masing -masing profil. Namun, masing -masing dapat diwakili untuk pihak ketiga menggunakan catatan DNS yang berbeda. Dalam hal ini, cukup buat direktori baru di bawah // freeswitch/conf/ssl/untuk setiap catatan DNS . Kemudian tempatkan agen.PEM dan CAFILE.PEM ke masing -masing direktori. Arahkan setiap profil ke direktori individual yang berisi agen spesifiknya.file PEM.

Pemecahan masalah

Masalah dengan TLSV1

Jika Anda telah memilih konfigurasi ini di profil SIP _ Anda:

Ada sejumlah gotcha dan snafus yang dimungkinkan dengan TLS. TLS berjalan di TCP, bukan UDP, jadi pastikan firewall mana pun dikonfigurasi untuk bekerja dengan TCP. Menghasilkan sertifikat yang tepat, dan pastikan dimuat ke telepon atau ATA. Juga, pastikan bahwa waktu dikonfigurasi dengan benar pada titik akhir Anda karena Anda akan mendapatkan pesan kesalahan “sertifikat buruk” samar jika waktu terlalu jauh, dan itu akan gagal untuk menjabat dengan benar. (Misalnya, sertifikat memiliki “tidak valid sebelum” dan “tidak valid setelah” atribut.) Jika ponsel Anda tidak akan mendaftar, atau gagal berfungsi dengan baik, Anda dapat mempertimbangkan untuk memeriksa daftar interoperabilitas, dan/atau dokumentasi ponsel dan revisi firmware Anda. Jika masih gagal bekerja dengan baik, Anda dapat menganggap SSLV23 sebagai fallback.

Masalah dengan SSLV23

Jika Anda telah memilih opsi konfigurasi ini di profil SIP _ Anda:

Ini akan memberi Anda kemampuan untuk mengenkripsi data. Keamanan mirip dengan dengan server web, akar tepercaya sertifikat dapat diperiksa, otentikasi sertifikat klien didukung, subjek dan tanggal sertifikat dapat divalidasi (beberapa di antaranya memang bergantung pada dukungan klien untuk fitur tersebut). Ini mungkin sebenarnya yang Anda inginkan, dan mengingat bahwa beberapa ponsel tidak mendukung TLS, tetapi mendukung SSL, Anda mungkin ingin mengkonfigurasi yang sesuai.

Jika profil SIP Anda gagal memulai

Jika Anda masuk ke FreeSwitch Cli dan ketik:

Anda mungkin menemukan bahwa profil SIP _ Anda yang Anda konfigurasi pengaturan TLS/SSL hilang. Jika itu masalahnya, Anda mungkin kehilangan paket libssl-dev atau agen.File PEM tidak ada atau memiliki izin yang salah. Pastikan pengguna Freeswitch berjalan seperti yang telah dibaca izin ke sertifikat dan kunci. Menghidupkan Sofia Tport Debug Logging ke High akan membantu mencetak kesalahan mengapa tidak memulai dengan benar. Lihat distribusi Anda untuk menginstal Paket Pengembangan OpenSSL. Ini diperlukan untuk kode yang melakukan enkripsi di dalam freeswitch untuk dikompilasi ke dalam biner. Mengaktifkan tingkat debug yang lebih tinggi di Sofia (Sofia Loglevel semua 9, atau Sofia Loglevel Tport 9 umumnya memberikan cukup) dan di konsol dapat membantu debug masalah dan masalah jabat tangan.

Kesalahan negosiasi tls ‘tidak ada cipher yang cocok’

Jika Anda menerima pesan kesalahan ‘tanpa cipher’, periksa terlebih dahulu untuk memastikan Anda telah menggabungkan kunci sertifikat Anda ke dalam agen Anda.file PEM. Jika Anda masih menerima kesalahan, meregenerasi kunci dan sertifikat dan membuat agen baru.PEM dengan kunci dan sertifikat baru, lalu coba lagi.

Langkah -langkah debugging lebih lanjut

Jika Anda masih mengalami masalah, TLS menjalankan berikut ini disarankan:

• ) atur Sofia Loglevel ke 9 ( < param name="log-level" value="9"/>) Di AutOLoad _ Configs/Sofia.conf.xml
• ) Set FreeSwitch Console Loglevel ke Debug (F8)
• ) Muat ulang mod _ sofia dan tinjau log
• ) Jika semuanya terlihat baik -baik saja di sisi server, coba gunakan freeswitch atau softphone berbasis freeswitch seperti fsclient atau fsomm. Ini akan memungkinkan Anda untuk melakukan hal yang sama di sisi klien (termasuk lampirkan FS _ CLI kepada mereka untuk mendapatkan data log) untuk mencoba dan melihat kesalahan apa pun yang mungkin dimiliki klien
• ) Resor terakhir menaruh semua log di pastebin dan meminta bantuan.

Menggunakan Freeswitch sebagai klien SSL/TLS

Freeswitch dapat berkomunikasi dengan server lain dan bertindak sebagai klien SIP (alias menggunakan gateway lain). Untuk melakukan ini, Anda harus memiliki kafil.PEM pada klien di folder conf/ssl dengan sertifikat CA. Anda juga akan membutuhkan agen.File PEM (ini dapat berupa pasangan kunci publik/pribadi yang dihasilkan secara acak atau sertifikat klien yang valid) dalam folder yang sama yang digunakan sebagai sertifikat klien.

Opsi TLS tingkat lanjut

Freeswitch mendukung beberapa parameter TLS lanjutan di pengaturan profil lihat file konfigurasi sofia untuk detailnya.

Pengaturan cepat SSLV23 dengan SRTP

Instal cepat pada profil internal jika server internal host Anda adalah PBX.Freeswitch.org:

./gentls_cert setup -cn pbx.Freeswitch.org -alt dns: pbx.Freeswitch.org -org freeswitch.org ./gentls_cert create_server -cn pbx.Freeswitch.org -alt dns: pbx.Freeswitch.org -org freeswitch.org

Jika klien Anda mendukung/memvalidasi sertifikat server, salin CA Certificate Conf/SSL/Cafile.PEM untuk klien Anda.

Mintalah klien Anda terhubung ke FreeSwitch di port 5061, bukan 5060 dan mengaktifkan TLS (dan jika mungkin SRTP) pada klien. Jika klien Anda freeswitch pengaturan transport = TLS di bawah tls-bind-param di samping opsi aktifkan di atas dari server. Akhirnya di server FreeSwitch Anda untuk panggilan yang terikat untuk klien, Anda akan ingin mengaktifkannya untuk memeriksa SRTP dengan mengatur RTP _ Secure _ Media = true untuk panggilan (lihat Langkah 5 di bawah ini untuk detail lebih lanjut tentang bagaimana melakukan ini secara lebih program untuk klien yang hanya mendukung ini).

Mulai ulang server FreeSwitch Anda (atau muat ulang mod _ sofia) dan mintalah klien Anda terhubung dan Anda harus dapat membuat dan menerima panggilan yang aman! Untuk meningkatkan keamanan periksa opsi TLS lengkap dan mengaktifkan pemeriksaan sertifikat (juga untuk menghentikan MITM).

Langkah 5 – Mengamankan Saluran RTP (Opsional)

Panggilan yang berasal dari telepon memiliki RTP _ Secure _ set media jika TLS diatur. Periksa ekstensi global. Ada bagian yang berkomentar bahwa keluar akan membutuhkan SRTP di kaki keluar jika kaki masuk dienkripsi. Mengaktifkan ini akan bermasalah dengan sebagian besar ITSP karena mereka tidak mendukung TLS.

Untuk panggilan yang berasal dari (atau dialihkan melalui) FreeSwitch dan diakhiri pada pengguna/ titik akhir (e.G., Panggilan ke telepon), perubahan berikut akan memungkinkan SRTP jika titik akhir terdaftar di TLS. Perhatikan bahwa ini adalah konfigurasi yang valid untuk mendaftar dengan TLS tetapi tidak memerlukan SRTP. Ini menonaktifkan opsi konfigurasi yang valid untuk pengguna/ titik akhir. Ini juga akan membutuhkan penyempurnaan lebih lanjut untuk mendukung ZRTP pada pengguna/ titik akhir yang terhubung dengan TLS. Dalam hal ini, pendekatan yang lebih baik adalah mengatur sesuatu pada entri direktori pengguna yang menentukan enkripsi RTP mana yang akan didukung. (Dengan kata lain, ada alasan ini bukan pengaturan default.)

Edit Conf/Direktori/Default.xml dan ubah dial-string param untuk:

Mengapa itu ide yang bagus

Di primer enkripsi SIP di atas kami membahas mengapa mengenkripsi data RTP mungkin merupakan ide yang bagus. Ini sebagian besar dilakukan di dialplan dan memiliki halaman sendiri yang didedikasikan untuk fungsinya.

SRTP dengan sendirinya tanpa TLS tidak aman karena tombol dipertukarkan antara dua titik akhir di SIP yang jelas, yang tidak aman tanpa TLS atau SSL.

Lihat Halaman RTP Aman untuk Cara Menyebarkan SRTP.

Perhatikan bahwa parameter SIP_SECURE_MEDIA tidak lagi diimplementasikan dan Anda harus mengatur RTP_SECURE_MEDIA

Untuk koneksi yang benar -benar aman (pensinyalan + media) Gunakan TLS + SRTP. TLS tanpa SRTP mengamankan SIP. SRTP tanpa TLS tidak benar -benar mengamankan RTP!

Langkah 6 – Catatan DNS NAPTR & SRV (Opsional)

Mengkonfigurasi DNS NAPTR dan SRV untuk TLS

Ini tidak diperlukan karena TLS akan berfungsi tanpanya, tetapi disarankan. Jika Anda akan mengatur TLS, Anda mungkin meluangkan waktu untuk mengatur catatan DNS SRV dan NAPTR yang benar.

Berikut adalah contoh catatan NAPTR yang Anda perlukan (buat subtitusi untuk “domain.com “seperlunya):

domain.com. Dalam NAPTR 10 0 “S” “SIPS+D2T” “” _SIPS._tcp.domain.com.
domain.com. Dalam NAPTR 20 0 “S” “SIP+D2T” “” _SIP._tcp.domain.com.
domain.com. Dalam NAPTR 30 0 “S” “SIP+D2U” “” _SIP._udp.domain.com.

Jika Anda mengkonfigurasi dengan –enable-sctp dan memiliki sctp dimuat di linux, Anda dapat menambahkan catatan ini:

domain.com. Dalam NAPTR 10 0 “S” “SIPS+D2S” “” _SIP._sctp.domain.com.

Maka Anda ingin mengatur catatan SRV ini selain NAPTR di atas:

_SIPS._tcp.domain.com. Di SRV 10 0 5061 SIP.domain.com.
_menyesap._udp.domain.com. Di SRV 10 0 5060 SIP.domain.com.
_menyesap._tcp.domain.com. Di SRV 10 0 5060 SIP.domain.com.

Jika Anda mengkonfigurasi dengan –enable-sctp dan memiliki sctp dimuat di linux, Anda dapat menambahkan catatan ini:

_menyesap._sctp.domain.com. Di SRV 10 0 5060 SIP.domain.com.

Contoh: SNOM Phones akan sepenuhnya menghormati NAPTR dan SRV seperti halnya sofia-sip pada panggilan keluar yang berasal dari Freeswitch.