SIP TLS
Streszczenie:
1. Freeswitch wymaga agenta.plik PEM z prawidłowymi uprawnieniami do działania jako serwer TLS.
2. Bezpieczeństwo warstwy transportowej (TLS) to protokół używany do ochrony SIP Wiadomości przed przechwyceniem.
3. TLS to ewolucja wcześniejszego protokołu SSL używanego do szyfrowania sieci.
4. Certyfikaty i kryptografia asymetryczna to kluczowe elementy TLS.
5. Certyfikaty są używane do uwierzytelniania podmiotów, a organy certyfikatu weryfikują ich autentyczność.
6. Symetryczna i asymetryczna kryptografia jest używana do szyfrowania danych i deszyfrowania.
7. TLS wykorzystuje kryptografię symetryczną do uwierzytelniania i kryptografii asymetrycznej do szyfrowania danych masowych.
8. TLS można wykorzystać do bezpiecznego ustanowienia rozmów SIP w niezabezpieczonym Internecie.
9. Freeswitch obsługuje zaszyfrowaną sygnalizację (SIPS) z podpisanymi certyfikatami i zaszyfrowanymi audio/nośnikami (SRTP).
10. Freeswitch umożliwia konfigurację portu dla SIPS w profilu SIP.
Pytania:
1. Jakiej pliku wymaga FreeSwitch do działania jako serwer TLS?
Odpowiedź: Freeswitch wymaga agenta.plik PEM.
2. Dlaczego ważne jest, aby mieć odpowiednie uprawnienia dla agenta.pem?
Odpowiedź: Nieprawidłowe uprawnienia mogą uniemożliwić prawidłowe działanie słuchacza TLS.
3. Do czego jest używane w SIP?
Odpowiedź: TLS służy do ochrony SIP Wiadomości przed przechwyceniem.
4. Jaka jest różnica między TLS i SSL?
Odpowiedź: TLS to ewolucja SSL i jest używana zarówno w protokole internetowej, jak i rzeczywistej, takich jak SIP.
5. Do jakich certyfikatów używanych w TLS?
Odpowiedź: Certyfikaty służą do uwierzytelniania jednostek.
6. Jaki jest cel organów certyfikatów?
Odpowiedź: Władze certyfikatów weryfikują autentyczność certyfikatów.
7. Jakie są dwa rodzaje kryptografii używane w TLS?
Odpowiedź: Symetryczna i asymetryczna kryptografia.
8. Jak działa kryptografia symetryczna?
Odpowiedź: Dane są szyfrowane i odszyfrowane za pomocą tego samego klucza.
9. Jak działa asymetryczna kryptografia?
Odpowiedź: Dane są szyfrowane i odszyfrowane za pomocą klucza publicznego i klucza prywatnego.
10. Do czego TLS używa kryptografii symetrycznej?
Odpowiedź: TLS używa kryptografii symetrycznej do uwierzytelnienia.
11. Do czego TLS wykorzystuje asymetryczną kryptografię?
Odpowiedź: TLS wykorzystuje kryptografię asymetryczną do szyfrowania danych masowych.
12. Czy TL można wykorzystać do nawiązywania bezpiecznych rozmów SIP w niezabezpieczonym Internecie?
Odpowiedź: Tak, TLS może być używany do bezpiecznych rozmów SIP w niezabezpieczonym Internecie.
13. Co obsługuje FreeSwitch pod względem zaszyfrowanej sygnalizacji?
Odpowiedź: FreesWitch obsługuje zaszyfrowaną sygnalizację znaną jako SIPS.
14. Jaki jest domyślny port dla SIPS?
Odpowiedź: Domyślnym portem dla SIPS jest port TCP 5061.
15. Co można skonfigurować w profilu SIP w FreesWitch?
Odpowiedź: Port dla SIP można skonfigurować w profilu SIP w FreeSwitch.
SIP TLS
Freeswitch wymaga tylko jednego pliku do działania jako serwer TLS i to jest agent.plik PEM. Zawiera certyfikat i klucz, którego użyje do słuchania. Pamiętaj, że niezwykle ważne jest, aby Twój agent.PEM (i opcjonalnie Cacert.PEM) mieć uprawnienia do odczytu dla użytkownika FreeSwitch. Oznacza to, że jeśli używasz -u freeswitch, chcesz „chmod 640 agent.Pem Cacert.PEM „i„ Chown Root.Agent Freeswitch.Pem Cacert.PEM “. Nieprawidłowe uprawnienia nie pozwolą słuchaczowi TLS poprawnie się zwrócić. Na twoich vars.XML:
Zrozumienie bezpieczeństwa warstwy transportowej (TLS)
W ciągu kilku artykułów na blogu I’wspomniał o niektórych aspektach bezpieczeństwa SIP. Udowadniając to z uwierzytelnianiem SIP, omówiłem użycie wiadomości odpowiedzi i nagłówków uwierzytelniania. Tego rodzaju bezpieczeństwo jest dostarczane na poziomie protokołu. Innymi słowy, SIP klienci i serwery wymieniają wiadomości, które egzekwują bezpieczeństwo na poziomie tożsamości. Oczywiście, ponieważ sam SIP jest protokołem tekstowym, potrzebujemy czegoś, co chroni wiadomości i ich treści przed wścibskimi oczami. Wchodzić Bezpieczeństwo warstwy transportowej (Tls).
TLS to ewolucja wcześniejszego protokołu nazywanego Bezpieczna warstwa gniazda (SSL). SSL został opracowany wiele lat temu przez Netscape (pamiętaj o Netscape?) i był używany do szyfrowania danych wysyłanych między przeglądarką internetową a serwerem WWW. Wiedziałeś, że używasz SSL, gdy zawiera linia adresu przeglądarki “https” i nie “http.” Niektóre przeglądarki wyświetlałyby również symbol blokady, gdy SSL był używany.
Podobnie jak większość innych protokołów używanych przez SIP, TLS jest kontrolowany przez Internetowa grupa zadaniowa inżynierii (IETF). Na początku TLS i SSL Weren’t co się różni od siebie. Jednak od pierwotnej definicji w 1999 r. TLS nadal przekształca się w wysoce bezpieczny protokół transportu zarówno dla protokołów internetowych, jak i w czasie rzeczywistym, takich jak SIP.
U podstaw TLS są certyfikaty i koncepcje symetryczny I Asymetryczna kryptografia. Mógłbym napisać tysiące słów o tych trzech, ale możesz nauczyć się wystarczająco, aby być niebezpiecznym w kilku akapitach.
Po pierwsze, certyfikat jest formą cyfrowego identyfikatora, którego jednostka używa do identyfikacji. Pomyśl o tym jak o kierowcy’licencja na komponenty IP. Jednak, aby zapobiec wykutaniu paskudnych ludzi’licencje, Władze certyfikatów (Ca) istnieją, które są używane do potwierdzenia autentyczności certyfikatu. Istnieje prywatna CAS, którą działa przedsiębiorstwo. Istnieje również publiczne CA, które są dostępne przez Internet. Verisign jest przykładem znanej publicznej CA.
Następnie pojawia się symetryczna i asymetryczna kryptografia. Oba mają związek z tym, w jaki sposób dane są szyfrowane i niezaszyfrowane. W przypadku kryptografii symetrycznej dane są szyfrowane kluczem. To’s również niezaszyfrowany z tym samym kluczem. Tak więc, jeśli dwa różne podmioty mają ten klucz, mogą wysłać zaszyfrowane dane w przód iw tył i nikt bez tego klucza nie zrozumie, co mówią. Siła symetrycznej kryptografii polega na tym, że jest ona szybka i wykorzystuje minimalną moc przetwarzania. Słabość polega na tym, że potrzebujesz bezpiecznego mechanizmu, aby wymienić klucz.
Dane są również szyfrowane za pomocą asymetrycznej kryptografii, ale w tym przypadku są dwa klucze – klucz publiczny i prywatny. Klucz publiczny jest zwykle zawarty w ramach certyfikatu jednostki IP, a każdy, kto ma ten certyfikat, będzie miał klucz publiczny. Klucz prywatny jest utrzymywany w tajemnicy i nigdy nikomu nie ujawnia. Te dwa klucze współpracują ze sobą, aby szyfrować i odszyfrować dane wysyłane na połączeniu IP.
Dane zaszyfrowane za pomocą klucza publicznego mogą być niezaszyfrowane tylko za pomocą powiązanego klucza prywatnego. Dane zaszyfrowane za pomocą klucza prywatnego mogą być niezaszyfrowane tylko za pomocą pasującego klucza publicznego. Ta forma szyfrowania jest znana jako Kryptografia klucza publicznego. Wymaga większej mocy obliczeniowej niż kryptografia symetryczna, ale tworzy bezpieczny link do danych, który tylko klient i serwer mogą rozszyfrować.
Napisałem, że TLS używa zarówno kryptografii symetrycznej, jak i asymetrycznej. Wykorzystuje symetryczne do uwierzytelniania i asymetryczne do szyfrowania danych masowych. W naszym przypadku masowe dane byłyby wiadomości i odpowiedzi SIP. Zauważ, że te dane nie obejmują rzeczywistego przepływu mediów, takiego jak g.711 lub g.729. Te dane są szyfrowane za pomocą Bezpieczny protokół w czasie rzeczywistym (Srtp) – blog na kolejny dzień.
Jeśli nadal czytasz, oklaskiwam twoją wytrwałość. To nie jest łatwe do zrozumienia. Pamiętaj jednak o następujących punktach i powinno być dobrze. Certyfikaty służą do weryfikacji autentyczności klientów i serwerów. Istnieją organy certyfikatów, aby sprawdzić, czy certyfikaty nie są kuszenia. Klucze publiczne i prywatne są używane do szyfrowania wiadomości wymienianych między podmiotami SIP. Oznacza to, że dzięki TLS możesz bezpiecznie korzystać z niezabezpieczonego Internetu, aby ustanowić bezpieczne rozmowy SIP. Nawet jeśli wiadomości SIP są przechwycone, wygrały’nie robią nikogo dobrego, ponieważ nie będą w stanie zrozumieć, co się mówi.
SIP TLS
Freeswitch obsługuje zarówno zaszyfrowaną sygnalizację znaną jako SIPS, które mogą być SSL lub TLS z podpisanymi certyfikatami, a także zaszyfrowane audio/media znane jako SRTP. Typową konwencją jest posiadanie niezadowolonego kanału sterującego SIP na porcie UDP 5060 (chociaż standardy pozwalają również na użycie portu 5060 TCP) oraz szyfrowanego kanału SSL lub szyfrowanego kanału sterującego SIP znanego jako SIP na porcie TCP 5061 . Poniższe ilustracje przedstawiają SIP jako na porcie 5060 i SIP jako na porcie 5061 i porcie (x). FreesSwitch umożliwia skonfigurowanie tego portu w profilu SIP.
Dane RTP wykorzystują UDP, ale port, którego używa RTP, jest dynamiczny, ponieważ są negocjowane w kanale sterowania SIP. FreeSwitch można skonfigurować do używania określonego zakresu portów dla strumieni RTP. W rozdziale 1 tej strony przejdziemy przez anatomię połączenia SIP i możliwych konfiguracji, abyś mógł wybrać, która konfiguracja najlepiej pasuje do Twojego scenariusza i odpowiednio skonfigurować system FreesSwitch.
Anatomia połączenia SIP
Najpierw przejrzyjmy anatomię połączenia SIP w celu rozwiązywania wszelkich zamieszania, które może powstać z założenia, że szyfrowanie implikuje, że strumienie audio (lub RTP) są szyfrowane.
Na rycinie 1 zauważysz, że rzeczywiście istnieją trzy osobne połączenia, jedno TCP do kontroli, a pozostałe dwa to UDP do przekazywania strumieni dźwięku do iz przełącznika. Kanał kontrolny ułatwia szereg możliwości, ale w odniesieniu do szyfrowania tych, o które jesteśmy przede wszystkim zaniepokojeni, to cyfry DTMF wybierane podczas połączenia, takie jak pink bankowy lub inny rodzaj kodu dostępu, który jest osobisty i, co najważniejsze, prywatne informacje. W scenariuszu przedstawionym na rysunku 1 każdy w sieci może powąchać i dekodować te cenne dane.
Anatomia połączenia SIPS
Odpowiedź na ten problem jest przedstawiony na rysunku 2 i szyfrowanie kanału SIP za pomocą opakowania SSL lub TLS, tak że każdy wącha pakiety na drucie. Zauważysz, że na rysunku 2 przedstawiamy to jako na porcie 5061, ale z FreeSwitch możesz faktycznie skonfigurować go na dowolnym pragnieniu. Ten scenariusz nadal pozostawia pakiety dla danych audio. Ktoś wąchający pakiety będzie mógł odtworzyć twoją słyszalną rozmowę i „słuchać w” bez większych trudności.
* Notatka: Telefony IP mogą reklamować, że obsługują szyfrowanie, ale możesz sprawdzić specyfikacje, aby potwierdzić, że obsługują zarówno podpisane certyfikaty SSL, jak i TLS.
Anatomia połączenia SIPS i SRTP
Na rysunku 3 zauważysz, że kanał sterujący jest nie tylko szyfrowany, ale strumienie RTP są również szyfrowane i wysyłane jako SRTP. W ten sposób i tylko w ten sposób, cała twoja rozmowa jest dość bezpieczna przed podgrzewaniem. Jest to również ważne, ponieważ cyfry DTMF można również wysłać również w danych RTP (wband). Posiadanie zarówno SIPS, jak i szyfrowania SRTP jest najlepszą opcją, jeśli chodzi o upewnienie się, że połączenia SIP są bezpieczne.
* Notatka: Telefony IP mogą reklamować, że obsługują szyfrowanie, musisz sprawdzić specyfikacje telefonów, aby ustalić, czy obsługuje SRTP. Więcej zostanie powiedziane na ten temat poniżej wraz z problemami interoperacyjności z niektórymi telefonami na dole tej strony.
Możliwości szyfrowania Freeswitch
Ta strona obejmie tylko szyfrowanie TLS, SSL i SRTP.
Szyfrowanie TLS, SSL i SRTP
Freeswitch obsługuje SIPS za pośrednictwem SSL i/lub TLS, a także możliwości szyfrowania SRTP. Nie jest jasne, czy Freeswitch szyfrowuje strumienie wideo, ponieważ nie zostało to przetestowane w laboratorium KJV, jednak podejrzewam, że tak będzie. Jeśli przeprowadzasz testowanie szyfrowania wideo SRTP, z pewnością dodaj swoje wyniki do wiki.
Szyfrowanie ZRTP ZRTP jest teraz obchodzony i zostanie usunięty z dokumentów
ZRTP jest oportunistyczną zdolnością szyfrowania, którą można skompilować w FreesWitch. Zobacz stronę ZRTP, aby uzyskać porad i dodatkowe informacje dotyczące ZRTP.
Szyfrowanie hybrydowe
FreesWitch może w rzeczywistości zaszyfrować dane w celu przechodzenia przez niego ruchu SIP. W ten sposób możesz zapewnić szyfrowanie telefonów IP, które nie natywnie obsługują szyfrowania. Ponieważ istnieje mnóstwo sprzętu SIP, która nie obsługuje szyfrowania, ta konfiguracja może okazać.
Na rysunku 4. Ważne jest, aby zrozumieć, że w tej sytuacji SIP Control i RTP (audio) są zarówno niezaznaczone między telefonem IP, jak i Freeswitch. Stąd, jeśli Twój telefon SIP IP znajduje się gdzieś za routerem NAT na modemie kablowym, a FreesWitch nie jest za tym routerem, zarówno LAN telefonu, jak i połączenie internetowe z FreesWitchem są całkowicie otwarte, co oznacza, że ktoś może wąchać te pakiety i uzyskać cenne informacje.
Ponadto dane RTP (audio) między FreeSwitch a zdalnym punktem końcowym zilustrowanym jako „Inne SIP PBX” są również niezaszyfrowane i mogą być przechwycone, jednak kanał kontrolny dla tego połączenia jest szyfrowany, a zatem rozsądnie bezpieczny. Jeśli Freeswitch był na tym samym sieci, co telefon, możliwość przechwytywania jest mniejsza, ale dane audio są nadal zdolne do przechwytywania.
Na rysunku 5. Ta opcja zaszyfrowuje zarówno kanał sterujący, jak i dane audio dla połączeń między FreeSwitch i innymi punktami końcowymi, które obsługują szyfrowanie.
Nadal należy zrozumieć, że połączenie z telefonu do Freeswitch jest w całości zdolne do przechwytywania przez sniffer pakietu.
Wybór między opcjami szyfrowania
Istnieje wiele opcji szyfrowania Freeswitch, jak opisano powyżej. TLSV1 szyfruje wszystko przez połączenie TCP; Ma to wadę, że może wystąpić drganie lub opóźnienia w wyniku TCP. UDP jest ogólnie preferowany dla RTP, a korzystanie z TLSV1 ma dodatkowy koszt ruchu. Wreszcie jest SSLV23; To szyfruje kanał sterujący SIP przez zaszyfrowane połączenie TCP za pomocą certyfikatów SSL, ale domyślnie nie zapewnia nic dla danych RTP. Informacje logowania i metadane połączeń są przesyłane przez kanał kontrolny, więc jeśli zależy ci na ochronie, jest wystarczająca i nie dodaje żadnych kosztów danych RTP. Jeśli chcesz zaszyfrować same dane głosowe (aby dane głosowe nie można zrozumieć), można to połączyć z SRTP. SRTP umożliwia szyfrowanie danych RTP z niewielkim narzutem do każdego z pakietów RTP UDP. Ma to korzyść, że dane połączeń są szyfrowane, ale nadal są przekraczające UDP, więc nie powinno być praktycznie różnicy w SRTP. Klucz szyfrowania używany do SRTP jest wymieniany przez kanał sterujący (który szyfruje SSLV23), więc daje ci coś najlepszego z obu światów. Zasadniczo SSLV23 + SRTP jest najbardziej przyjazną dla zapory/mało zmian w istniejących instalacjach. SSLV23 + SRTP jest również dość łatwy do skonfigurowania na serwerze FreesSwitch i najprawdopodobniej najbardziej obsługiwana metoda szyfrowania dla większości klientów i telefonów SIP, więc ogólnie powinna być miejscem, w którym ktoś powinien zacząć szyfrować dane połączeń.
O telefonach IP i szyfrowaniu
Niektórzy dostawcy reklamują, że ich produkt obsługuje szyfrowanie SIP. Pytanie brzmi, jak dobrze obsługuje szyfrowanie SIP. Przejrzyjmy więc tę skomplikowaną zagadkę marketingową.
- Telefon może obsługiwać SSL i/lub TLS Szyfrowany SIP, czyli „popijanie”.
- Telefon może posunąć się tak daleko, aby obsługiwać TLS z podpisanymi certyfikatami.
- Oprócz tych zastrzeżeń telefon może posunąć się tak daleko, aby obsługiwać zaszyfrowane dane audio SRTP.
- Wreszcie upewnij się, że telefon IP obsługuje standard SIPS i/lub szyfrowanie SRTP. Zasadniczo nie jest zbyt daleko, aby producent wymyślił metodę szyfrowania włosów, która działa tylko z ich produktami.
OSTRZEŻENIE: Sprawdź specyfikacje i wykonaj badania przed zakupem dowolnego telefonu IP SIP, który reklamuje się jako zdolny do wykonywania szyfrowania. Możesz także sprawdzić, czy istnieją jakieś problemy z wersją oprogramowania układowego SIP, w którym działa telefon, a jego interoperacyjność z FreeSwitch.
Ograniczenia implementacji Freeswitch TLS/SSLV23 (FS-3877)
Niestety domyślna konfiguracja LIB _ SOFIA STACK i FREESwitch ma jedno domyślne (prawdopodobnie nieoczekiwane) zachowanie, które może powodować problemy z szyfrowaniem trudno do diagnozy. Kiedy klient łączy się z serwerem, tworzy zaszyfrowany kanał TCP używany do komunikowania się z serwerem. Za każdym razem, gdy składa rozmowę, rejestry itp., robi to za pomocą tej sesji TCP. Niestety, kiedy Freeswitch próbuje komunikować się z klientem, aby powiedzieć o tym o przychodzącym połączeniu, powiadomieniach itp., Ustanawia drugi kanał TCP z serwera do klienta. Chociaż jest to szyfrowane, może to powodować pewne problemy dla niektórych konfiguracji zapory i wielu opcji bezpieczeństwa TLS/SSL w FreeSwitch. Jeśli FreeSwitch nie może ustalić tego kanału, klient będzie mógł wykonywać połączenia, ale nie będzie mógł odbierać połączeń (ani niczego innego, co pochodzi od serwera do klienta). Ponadto wiele cech TLS może działać nieoczekiwanie, więc należy wziąć pod uwagę kierunek. Na przykład TLS-Verify-Policy Set na „Out” spowodowałby, że Freeswitch próbowałby zweryfikować certyfikat klienta, gdy połączy się on z klientem, więc nawet jeśli klient początkowo łączy się z serwerem, a to pominął walidację połączeń z serweru-> klienta, Freeswitch go zweryfikowałby. Ponadto może to otworzyć otwory bezpieczeństwa, na przykład ustawianie zasady na „w” w celu weryfikacji przychodzących klientów nie zweryfikowałoby certyfikatu klienta, gdy serwer powiązał się z klientem, co pozwoliłoby na atak MITM tam. Rzeczy takie jak walidacja tematu może być również trudna, zwłaszcza jeśli Freeswitch działa jako klient. Na przykład sprawdzanie sprawdzania tematu sprawdza nazwę hosta, do której Freeswitch łączy się z certyfikatem zwykłą nazwą, podczas gdy ładny kontrola bezpieczeństwa nie może być wykonywana, gdy serwer łączy się z FreeSwitch (jak w tym momencie Freeswitch faktycznie próbuje sprawdzić adres IP pod względem nazwy wspólnej). Ponadto walidacja celu (upewnienie się, że Freeswitch łączy się z serwerem, to certyfikat wydany dla serwera, a nie klienta lub odwrotnie) nie jest obsługiwana. Umożliwia to ataki MITM na serwer FreesSwitch za pomocą certyfikatu klienta (lub odwrotnie), ale ze względu na połączenie w obie strony, sprawdzanie poprawności celu nie jest obecnie obsługiwane (ponieważ połączenie przychodzące może pochodzić z certyfikatu serwera podczas łączenia się). Tak więc, podczas gdy Freeswitch’s Gentls _ Cert właściwie przypisuje cel, którego nie jest obecnie używany przez samego FreeSwitch. Jednym z rozwiązań, które uniknie tej dziury MITM, jest wydanie certyfikatów klientów z innego CA.
Konfiguracja
Freeswitch obsługuje szyfrowanie ruchu sygnalizacyjnego SIP za pośrednictwem SSL i/lub TLS. Konwencja ma uruchomić SIPS na porcie 5061 . Możliwe są bardziej złożone konfiguracje, jednak nie zostaną one omówione w tej dokumentacji.
Będziesz potrzebować następujących informacji, aby skompilować FreeSwitch z obsługą szyfrowania TLS:
- Zainstalowany pakiet LibssL-dev (OpenSSL Development.
Jeśli nie masz zainstalowanego pakietu libssl-dev, problemem będzie profil SIP _, który zawiera dyrektywy konfiguracji szyfrowania określone poniżej w kroku 2.
Jeśli skompilowałeś FreesSwitch bez zainstalowanego tego pakietu, nie będzie obsługi szyfrowania i będziesz musiał go ponownie skompilować po zainstalowaniu pakietu Libssl-dev.
W przypadku debian do akt instalacji libssl-dev (na Lenny instaluj libcurl4-openssl-dev), a następnie skompiluj.
Krok 1 – Wygeneruj certyfikat CA (root)
Aby korzystać z TLS/SSL, potrzebujesz co najmniej dwóch certyfikatów: certyfikatu Root (CA) i certyfikatu dla każdego serwera. Jest skrypt pod adresem // freeswitch/bin/gentls _ cert lub w źródle Tarball /Scripts/Gentls _ Cert To pomaga wygenerować te pliki. Zakładając, że nazwa DNS twojego Freeswitch PBX to PBX.FreesWitch.org, z
./gentls_cert konfiguracja -cn pbx.FreesWitch.org -alt dns: pbx.FreesWitch.org -org freeswitch.org
To utworzy certyfikat CA i klucz wraz z katalogiem CONF/SSL/CA i certyfikat w folderze Conf/SSL.
[[[ Notatka: Nazwa podana dla -cn i -alt powinna być taka sama jak nazwa DNS instalacji Freeswitch i używana jako nazwa rejestracyjna w telefonie (przynajmniej na Polycoms). ] Możesz zmienić wiersz „dni = 2190” w pliku Gentls _ Cert, aby certyfikat był ważny na dłuższy czas. Jednak wydaje się, że to zbyt długo ma problem z owijaniem, wydaje się.
Krok 2 – Wygeneruj certyfikat serwera
./gentls_cert create_server -cn pbx.FreesWitch.org -alt dns: pbx.FreesWitch.org -org freeswitch.org
tworzy certyfikat serwera pod adresem // freeswitch/conf/ssl/agent.pem. Ten plik zawiera certyfikat i klucz prywatny. Powinien zawierać nazwę domeny we wspólnej i alternatywnej nazwie. Jeśli chcesz generować certyfikaty dla innych serwerów, użyj flagi -out dla gentls _ cert, aby określić certyfikat wyjściowy/nazwę pliku klawisza i skopiuj je na serwerze zdalnego.
Aby skonfigurować nowy CA i utworzyć nowy certyfikat w systemie Windows, przejdź tutaj.
Aby nowy certyfikat miał obowiązywać (jedyny sposób na użycie Freeswitch), Freeswitch musi zostać ponownie uruchomiony.
Notatka: Nazwa podana dla -cn i -alt powinna być taka sama jak nazwa DNS instalacji Freeswitch i używana jako nazwa rejestracyjna w telefonie (przynajmniej na Polycoms). Jest to wymagane w przypadku gałki do gałek (i prawdopodobnie też Pangoliina).
Przejrzyj swój certyfikat
Możesz sprawdzić swoje szczegóły certyfikatu za pomocą polecenia:
Openssl x509 -Noout -inform Pem -text -in/usr/local/freeswitch/conf/ssl/agent.pem
Krok 3 – Konfiguracja profilu Sofia
Freeswitch wymaga tylko jednego pliku do działania jako serwer TLS i to jest agent.plik PEM. Zawiera certyfikat i klucz, którego użyje do słuchania. Pamiętaj, że niezwykle ważne jest, aby Twój agent.PEM (i opcjonalnie Cacert.PEM) mieć uprawnienia do odczytu dla użytkownika FreeSwitch. Oznacza to, że jeśli używasz -u freeswitch, chcesz „chmod 640 agent.Pem Cacert.PEM „i„ Chown Root.Agent Freeswitch.Pem Cacert.PEM “. Nieprawidłowe uprawnienia nie pozwolą słuchaczowi TLS poprawnie się zwrócić. Na twoich vars.XML:
Uwaga: TLS jest domyślnie wyłączony; Ustaw wewnętrzny _ SSL _ Włącz i/lub zewnętrzny _ SSL _ Włącz „True”, aby włączyć.
Krok 4 Konfiguracja klienta
Wszyscy klienci powinni mieć przynajmniej zainstalowany certyfikat główny CA, aby zapewnić bezpieczeństwo. Bez włączania weryfikacji łańcucha (że certyfikat serwera został wydany przez zatwierdzoną CA) Atak MITM jest możliwy przeciwko klientowi. Certyfikat CA to CONF/SSL/CAFILE.PEM zawiera tylko certyfikat, a klienci używają go, aby upewnić się, że certyfikat serwera jest wydawany przez CA. Ponadto możesz chcieć (lub musisz polegać na urządzeniu) zainstaluj certyfikat klienta wydany przez ten sam CA. Możesz wygenerować certyfikat klienta za pomocą polecenia:
./gentls_cert create_client -cn client1 -out client1
To utworzy klienta1.PEM (zwróć uwagę na to, że nazwa zwyczajowa nie ma tak naprawdę znaczenia, rzadko serwer byłby kiedykolwiek umożliwiany sprawdzenie tematu certyfikatu klienta, abyś mógł ustawić to na to, czego chcesz). Niniejszy certyfikat/para kluczy powinna zostać zainstalowana na kliencie (zalecany inny dla każdego klienta dla bezpieczeństwa), ale nie musi pozostać na serwerze, nawet jeśli chcesz, aby serwer weryfikował certyfikat klienta. Jeśli klient jest kolejnym serwerem Freeswitch, który klient1.PEM, chcesz zmienić nazwę na agenta.pem. UWAGA Jeśli drugi serwer Freeswitch będzie również używał tego certyfikatu jako serwera, a nie tylko klienta, upewnij się, że wykonaj powyższe kroki za pomocą polecenia Utwórz _ serwer, aby utworzyć certyfikat serwera.
Certyfikaty handlowe
Większość certyfikatów komercyjnych serwerów internetowych powinna działać dla Freeswitch. Na przykład certyfikaty Thawte SSL123 (ich najtańsza opcja) są znane z tego, że działają w co najmniej jednej instalacji. Jeśli masz wątpliwości co do tego, czy certyfikat będzie działał, powinieneś kupić certyfikat tylko od firmy oferującej 30-dniową politykę zwrotu.
Wiele profilu TLS
Jeśli masz wiele profili SOPI SIP, możesz uważać, że możesz włączyć obsługę TLS dla każdego z profili. Jednak każda z nich może być reprezentowana dla stron trzecich przy użyciu innego rekordu DNS. W takim przypadku po prostu utwórz nowy katalog pod // freeswitch/conf/ssl/dla każdego rekordu DNS . Następnie umieść agenta.PEM i CAFILE.PEM do każdego z katalogów. Wskaż każdy profil na poszczególne katalog, który zawiera swój konkretny agent.plik PEM.
Rozwiązywanie problemów
Problemy z TLSV1
Jeśli zdecydowałeś się na tę konfigurację w swoim profilu SIP:
Istnieje wiele gotchas i snafus z tls. TLS działa na TCP, a nie UDP, więc upewnij się, że wszelkie zapory są skonfigurowane do pracy z TCP. Wygeneruj odpowiedni certyfikat i upewnij się, że jest on załadowany do telefonu lub ATA. Upewnij się również, że czas jest prawidłowo skonfigurowany w punkcie końcowym, ponieważ otrzymasz tajemnicze komunikaty o błędach „złego certyfikatu”, jeśli czas jest zbyt daleko, i nie uda się poprawnie uścisku dłoni. (Na przykład certyfikaty mają „nie ważne wcześniej” i „nie ważne po„ atrybutach.) Jeśli telefon nie zarejestruje się lub nie będzie działać poprawnie, możesz rozważyć sprawdzenie listy interoperacyjności i/lub dokumentacji telefonów i wersji oprogramowania układowego. Jeśli nadal nie działa poprawnie, możesz uznać SSLV23 za awarię.
Problemy z SSLV23
Jeśli zdecydowałeś się na tę opcję konfiguracji w swoim profilu SIP:
To da ci możliwość szyfrowania danych. Bezpieczeństwo jest podobne do serwerów internetowych, można sprawdzić zaufane certyfikaty, uwierzytelnianie certyfikatów klienta jest obsługiwane, tematy i daty certyfikatów można zatwierdzić (niektóre z nich zależą od obsługi klienta dla tej funkcji). To może być to, czego chcesz i biorąc pod uwagę, że kilka telefonów nie obsługuje TLS, ale obsługuje SSL, możesz odpowiednio skonfigurować.
Jeśli Twój profil SIP nie uruchomi się
Jeśli wejdziesz do Freeswitch CLI i wpisz:
Może się okazać, że brak profilu SIP, dla którego brakuje ustawień TLS/SSL. Jeśli tak jest, prawdopodobnie brakuje Ci pakietu Libssl-dev lub agenta.Plik PEM nie jest w miejscu lub ma nieprawidłowe uprawnienia. Upewnij się, że użytkownik FreeSwitch działa w zależności od uprawnień do odczytu certyfikatów i kluczy. Włączanie rejestrowania debugowania Sofia TPOR do High pomoże wydrukować błędy na temat tego, dlaczego nie uruchamia się prawidłowo. Zapoznaj się z dystrybucją, aby zainstalować pakiet programistyczny OpenSSL. Jest to konieczne, aby kod, który wykonuje szyfrowanie w FreeSwitch, aby skompilować binarne. Umożliwienie wyższego poziomu debugowania w Sofii (Sofia Loglevel All 9 lub Sofia Loglevel TPORT 9 ogólnie daje wystarczająco dużo), a w konsoli może pomóc w debugowaniu problemów i problemów z uściskiem dłoni.
TLS Błąd negocjacji „Brak pasujący szyfr”
Jeśli otrzymasz komunikat o błędzie „Brak pasującego szyfru”, najpierw sprawdź, aby upewnić się, że połączyłeś swój klucz certyfikatu w agenta.plik PEM. Jeśli nadal otrzymujesz błąd, zregeneruj zarówno klucz, jak i certyfikat i zrób nowy agent.PEM z nowym kluczem i certyfikatem, a następnie spróbuj ponownie.
Dalsze kroki debugowania
Jeśli nadal masz problemy z uruchomieniem TLS, sugerowane są następujące:
- ) Ustaw logowanie Sofia na 9 ( < param name="log-level" value="9"/>) W Autoload _ Configs/Sofia.conf.XML
- ) Ustaw logowanie konsoli Freeswitch na debugowanie (F8)
- ) Załaduj mod _ sofia i przejrzyj dzienniki
- ) Jeśli wszystko wygląda dobrze po stronie serwera, spróbuj użyć Freeswitch lub Freeswitch Fourthones, takich jak FSClient lub FSCOMM. Pozwolą ci to zrobić po stronie klienta (w tym dołączanie do nich FS _ CLI, aby uzyskać dane dziennika), aby spróbować i zobaczyć wszelkie błędy, które klient może popełnić klient
- ) Ostatnia nałóż wszystkie kłody na pastebinie i poproś o pomoc.
Używanie Freeswitch jako klienta SSL/TLS
Freeswitch może komunikować się z innym serwerem i działać jako klient SIP (czyli użyj innej bramy). Aby to zrobić, powinieneś mieć kawiarnię.PEM na kliencie w folderze Conf/SSL z certyfikatem CA. Będziesz także potrzebował agenta.plik PEM (może to być losowo wygenerowana para klucza publicznego/prywatnego lub prawidłowy certyfikat klienta) w tym samym folderze używanym jako certyfikat klienta.
Zaawansowane opcje TLS
Freeswitch obsługuje niektóre zaawansowane parametry TLS w ustawieniach profilu.
Szybka konfiguracja SSLV23 z SRTP
Szybka instalacja na profilu wewnętrznym, jeśli nazwa hosta wewnętrznego serwera to PBX.FreesWitch.org:
./gentls_cert konfiguracja -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
Jeśli Twoi klienci obsługują/sprawdzają certyfikat serwera Skopiuj certyfikat CA Conf/SSL/Cafile.PEM dla Twoich klientów.
Niech Twoi klienci połączą się z Freeswitch na porcie 5061 zamiast 5060 i włącz TL (i jeśli to możliwe, SRTP). Jeśli Twój klient jest freesWitch Ustawianie transportu = TLS w ramach TLS-Bind-Params oprócz powyższych opcji Włącz z serwera. Wreszcie na serwerze FreesWitch dla połączeń związanych z klientem będziesz chciał umożliwić mu przejście SRTP, ustawiając RTP _ Secure _ Media = True dla połączenia (zobacz krok 5 poniżej, aby uzyskać więcej informacji na temat tego, jak to zrobić więcej dla klientów, którzy tylko to obsługują).
Uruchom ponownie serwer FreesWitch (lub ponownie załaduj mod _ sofia) i mieć połączenie klienta i powinieneś być w stanie wykonywać i odbierać bezpieczne połączenia! Aby poprawić bezpieczeństwo, sprawdź pełne opcje TLS i włączyć sprawdzanie certyfikatów (również zatrzymanie MITM).
Krok 5 – Zabezpieczenie kanałów RTP (opcjonalnie)
Połączenia pochodzące z telefonu mają RTP _ Secure _ Zestaw multimediów Jeśli skonfigurowane jest TLS. Sprawdź globalne rozszerzenie. Komentowano sekcję, że OUT będzie wymagał SRTP na nodze wychodzącej, jeśli noga przychodząca zostanie zaszyfrowana. Włączenie to będzie problematyczne w przypadku większości ITSP, ponieważ nie obsługują TLS.
W przypadku połączeń pochodzących z (lub są kierowane) freeswitch i są zakończone w punkcie użytkownika/ punkcie końcowym (e.G., połączenia z telefonem), następująca zmiana włączy SRTP, jeśli punkt końcowy zarejestrowany w TLS. Zauważ, że jest to prawidłowa konfiguracja do rejestracji w TLS, ale nie wymaga SRTP. To wyłącza tę prawidłową opcję konfiguracji dla punktów użytkownika/ końcowego. Wymagałoby to również dalszego udoskonalenia obsługi ZRTP w punktach użytkownika/ końcowych, które łączą się z TLS. W takim przypadku lepszym podejściem byłoby ustawienie czegoś na wpisie katalogu użytkownika, które określa, które szyfrowanie RTP do obsługi. (Innymi słowy, istnieje powód, dla którego nie jest to ustawienie domyślne.)
Edytuj Conf/Directory/Default.xml i zmień Dial-String param do:
Dlaczego to dobry pomysł
W powyższym podkładu szyfrowania SIP omówiliśmy, dlaczego szyfrowanie danych RTP może być dobrym pomysłem. Odbywa się to w dużej mierze w Dialplan i ma własną stronę poświęconą jej funkcjonalności.
SRTP sam w sobie bez TLS nie jest bezpieczny, ponieważ klucze są wymieniane między dwoma punktami końcowymi w czystym SIP, co jest niepewne bez TLS lub SSL.
Zobacz bezpieczną stronę RTP, aby wdrożyć SRTP.
Zauważ, że parametr SIP_Secure_Media nie jest już zaimplementowany i powinieneś ustawić RTP_Secure_Media
Do całkowicie bezpiecznego połączenia (sygnalizacja + mediów) Użyj TLS + SRTP. TLS bez SRTP zabezpiecza SIP. SRTP bez TLS tak naprawdę nie zabezpiecza RTP!
Krok 6 – DNS NAPTR & SRV Records (opcjonalnie)
Konfigurowanie DNS NAPTR i SRV dla TLS
To nie jest wymagane, ponieważ TLS będzie działał bez niego, ale jest to zalecane. Jeśli zamierzasz skonfigurować TLS, możesz poświęcić czas na skonfigurowanie prawidłowych rekordów DNS SRV i NAPTR.
Oto przykład potrzebnych rekordów NAPTR (zrób napisy dla „domeny.com „w razie potrzeby):
domena.com. W NAPTR 10 0 „S” „SIPS+D2T” „„ _SIPS._TCP.domena.com.
domena.com. W NAPTR 20 0 „S” „SIP+D2T” „„ _sip._TCP.domena.com.
domena.com. W NAPTR 30 0 „S” „SIP+D2U” „„ _sip._udp.domena.com.
Jeśli skonfigurujesz za pomocą-Uneble-SCTP i masz załadowanie SCTP w Linux, możesz dodać ten rekord:
domena.com. W NAPTR 10 0 „S” „SIPS+D2S” „„ _sip._SCTP.domena.com.
Następnie będziesz chciał skonfigurować te rekordy SRV oprócz powyższego NAPTR:
_Sips._TCP.domena.com. W SRV 10 0 5061 SIP.domena.com.
_łyk._udp.domena.com. W SRV 10 0 5060 SIP.domena.com.
_łyk._TCP.domena.com. W SRV 10 0 5060 SIP.domena.com.
Jeśli skonfigurujesz za pomocą-Uneble-SCTP i masz załadowanie SCTP w Linux, możesz dodać ten rekord:
_łyk._SCTP.domena.com. W SRV 10 0 5060 SIP.domena.com.
Przykład: Snom Telefony w pełni uhonorują zarówno NAPTR, jak i SRV, podobnie jak Sofia-Sip na połączeniach wychodzących pochodzących z FreeSwitch.
