Czy dane są zawsze szyfrowane w komunikacji IPv6?


30

Nie mogę uzyskać prostej odpowiedzi na to pytanie. Wikipedia twierdzi, że „IPsec jest integralną częścią podstawowego zestawu protokołów w IPv6”, ale czy to oznacza, że ​​WSZYSTKIE komunikaty są zawsze szyfrowane, czy oznacza to, że szyfrowanie jest opcjonalne, ale urządzenia muszą być w stanie to zrozumieć (jeśli powinno się go użyć )?

Jeśli szyfrowanie jest opcjonalne, czy to system operacyjny decyduje, czy użyć szyfrowania, czy też aplikacja? Czy popularne systemy operacyjne i oprogramowanie zazwyczaj umożliwiają szyfrowanie?

Zbadałbym to sam, ale brakuje mi łączności IPv6.

Aktualizacja: Ok, więc jest opcjonalna. Moje dalsze pytanie: czy zazwyczaj jest to aplikacja, która określa, czy używać szyfrowania, czy też system operacyjny?

Konkretny przykład: Wyobraź sobie, że mam najnowszą wersję systemu Windows z natywną obsługą ipv6 i szukam czegoś na ipv6.google.com przy użyciu Mozilla Firefox. Czy byłby zaszyfrowany?


16
IPSec jest jak zamek w drzwiach; może to być część drzwi, ale to nie znaczy, że drzwi są koniecznie zamknięte.
Chris S

@Chris S: Niesamowity komentarz, mam na to głos.
SplinterReality

Odpowiedzi:


31

Nie.

IPv6 ma wbudowany protokół IPsec jako część protokołu i nie jest on zintegrowany, jak w przypadku protokołu IPv4. Nie oznacza to jednak, że jest domyślnie włączony, to po prostu oznacza (teoretycznie) niższy narzut na stosie sieciowym.

Zasadniczo użycie IPsec jest określane na poziomie IP stosu sieciowego, a zatem jest określane przez same zasady systemowe. np. System A może mieć politykę, która wymaga, aby zarówno AH, jak i ESP miały jakąkolwiek komunikację z podsiecią 4.0.0.0/8.

Aktualizacja: dla jasności aplikacja nie ma znaczenia - po prostu wie, że musi gdzieś otworzyć połączenie sieciowe i wysłać / odebrać dane. Następnie system musi ustalić, czy negocjować IPsec dla danego żądanego połączenia. Protokół IPsec jest w dużej mierze zaprojektowany jako mechanizm uwierzytelniania / szyfrowania niskiego poziomu i został celowo zbudowany, aby protokoły i aplikacje wyższego poziomu nie musiały się o to martwić.

To powiedziawszy, to tylko kolejna kontrola bezpieczeństwa na poziomie sieci i niekoniecznie powinna być używana w izolacji lub polegać na zagwarantowaniu „bezpieczeństwa” - jeśli próbujesz rozwiązać problem z uwierzytelnianiem, jest całkiem możliwe, że chcesz aplikacja do egzekwowania pewnego rodzaju uwierzytelnienia na poziomie użytkownika, pozostawiając uwierzytelnianie na poziomie komputera aż do IPsec.


1
Dziękujemy za wyraźne odrzucenie okropnie popularnego mitu.
Marcin

3
Och, rzeczy, które mogły być. Może dostaniemy to w IPv8 za kilkaset lat.
Michael Hampton

1
Nie zgadzam się - szyfrowanie powinno być zawsze możliwe, a w najlepszym razie bardzo łatwe. Nakazanie pewnego rodzaju kontroli bezpieczeństwa bez względu na istnienie innych kontroli jest trochę krótkowzroczne w odniesieniu do przypadków użycia, w których aktywnie nie chcesz szyfrowania na poziomie IP.
growse

20

Krótka odpowiedź: nie

Długa odpowiedź: IPsec brano pod uwagę przy projektowaniu IPv6 w tym sensie, że w przeciwieństwie do IPv4, IPsec (gdy jest używany) jest częścią nagłówka IPv6.

Więcej wyjaśnień: w IPv4 IPsec działa na samym IP. W rzeczywistości jest to protokół warstwy 4, który „zamaskowuje” jako protokół warstwy 3 (tak, że zwykłe protokoły L4 TCP i UDP nadal będą mogły działać). ESP (Encapsaping Security Payload) nie może rozdzielać pakietów IP. W rezultacie pakiety IPsec zwykle będą miały znacznie zmniejszoną pojemność użyteczną, jeśli zapobiegnie się fragmentacji. Dodatkowo, ponieważ jest na szczycie IP, nagłówek IP nie jest chroniony.

W IPv6 IPsec jest częścią samego IP. Może rozciągać się na pakiety, ponieważ nagłówek ESP jest teraz częścią nagłówka IP. A ponieważ jest zintegrowany z IP, można chronić więcej części nagłówka IP.

Mam nadzieję, że moje wyjaśnienie w skrócie jest wystarczająco jasne.


1
W rzeczywistości AH podpisuje cały pakiet, co oznacza, że ​​nic nie można zmienić (tzn. NAT go psuje.) Dlatego bardzo niewiele tuneli IPSec faktycznie używa AH. Jest to jeden z wielu nagłówków rozszerzeń , nie dosłownie „część nagłówka IP”.
Ricky Beam

2

Do Ciebie Dalsze pytanie:

System operacyjny określa, kiedy używać szyfrowania. Te opcje „zasad” znajdują się w panelach sterowania / zasadach konfiguracji. Mówisz rzeczy takie jak „jeśli chcesz połączyć się z dowolnym adresem w podsieci ab12 :: musisz mieć tajny Blah1234”. Istnieją opcje korzystania z PKI.

W tej chwili aplikacja nie może dodać do tej zasady ani zażądać skonfigurowania tej zasady. W sekcji ipv6 gniazda linux wspomniano: „Brakuje obsługi IPSec dla nagłówków EH i AH”. Ludzie myśleli o tym, ale obecnie nie są znane żadne działające implementacje.


1

Na twoje kolejne pytanie tak i nie.

Aplikacje mogą określać szyfrowanie, ale szyfrowanie odbywa się na poziomie aplikacji. Istnieje wiele różnych par nieszyfrowanych / szyfrowanych protokołów korzystających z różnych portów, takich jak HTTP / HTTPS, LDAP / LDAPS, IMAP / IMAPS i SMTP / SSMTP. Wszystkie używają szyfrowania SSL lub TLS. Niektóre usługi oferują opcję startTLS, która umożliwia uruchomienie szyfrowanego połączenia na normalnie nieszyfrowanym porcie. SSH to aplikacja, która zawsze używa szyfrowanego połączenia. W tych przypadkach szyfrowanie jest kompletne. (Istnieje algorytm szyfrowania NULL, którego można użyć, a zaszyfrowana treść zostanie przetransportowana w postaci niezaszyfrowanej).

IPSEC jest konfigurowany przez administratora, a aplikacja nie będzie wiedziała, czy połączenie jest szyfrowane. Widziałem głównie IPSEC używane do mostkowania ruchu między sieciami LAN przez niezabezpieczone połączenia (połączenia VPN). Wierzę, że IPSEC może dotyczyć tylko części trasy, więc w niektórych segmentach sieci dane są przesyłane w postaci czystej (niezaszyfrowanej).

Biorąc pod uwagę wybór, użyję szyfrowania aplikacji, ponieważ szyfrowanie sieciowe nie jest intensywnie używane.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.