Pytanie:
Dlaczego protokół TCP jest bezpieczniejszy niż UDP?
Philipp
2014-10-08 16:56:49 UTC
view on stackexchange narkive permalink

Niezupełnie.

Żaden protokół nie ma żadnych wbudowanych funkcji, które mają zapewnić poufność. Wszelkie zabezpieczenia powinny być zapewnione przez warstwy protokołów powyżej (lub poniżej).

TCP jest bardziej złożonym protokołem niż UDP, co sprawia, że ​​jest trochę trudniejszy do podrobienia, ale te komplikacje rzadko są poważną przeszkodą.

Kiedy ludzie mówią, że TCP jest „bardziej niezawodny” niż UDP, nie mówią o bezpieczeństwie. TCP jest bardziej niezawodny, ponieważ zapewnia, że ​​wszystkie segmenty są odbierane w kolejności, a wszystkie utracone segmenty są ponownie przesyłane. UDP tego nie gwarantuje. Gdy połączenie jest złe, segmenty UDP mogą zostać utracone bez śladu lub pojawić się w złej kolejności. Sposób rozwiązania tego problemu zależy od aplikacji.

Czy mógłbyś rozwinąć ostatni akapit? Co dokładnie masz na myśli, mówiąc „fałszerstwo”? O ile wiem, TCP jest nie tylko odrobinę trudniejsze do sfałszowania, ale w rzeczywistości jest o wiele trudniejsze do sfałszowania… jak naprawdę, naprawdę trudniejsze.
@Adnan Wolałbym nie rozwijać tego tematu, ponieważ i tak nie jest to temat na to pytanie (spoofing dotyczy naruszenia integralności, a nie poufności). Jeśli jesteś zainteresowany tym tematem, możesz otworzyć nowe pytanie.
Oh przepraszam. Może nie było jasne. Grzecznie powiedziałem, że twój ostatni akapit jest źle sformułowany, niskiej jakości i prawdopodobnie zawiera nieprawidłowe informacje (chyba że rozwiniesz). Nie prosiłem o dodatkowe informacje, mówiłem ci, żebyś poprawił swoją odpowiedź (na wypadek, gdyby była błędna, co jest jasne tylko wtedy, gdy rozwiniesz, co ** ty ** rozumiesz przez podszywanie się).
O ile wiem i proszę mnie poprawić, jeśli się mylę, kiedy mówisz o TCP / UDP i spoofingu, automatycznie zakłada się, że mówisz o nawiązaniu połączenia (w przypadku TCP), które wydaje się pochodzić z źródło, które nie jest prawdziwym źródłem. Chyba że masz na myśli proces inżynierii sieciowej Podszywanie się pod protokół https://en.wikipedia.org/wiki/Protocol_spoofing#TCP_spoofing (i nie sądzę, że o tym mówisz)
och, wygląda na to, że nie jestem jedynym zdezorientowanym przez źle sformułowany akapit, http://security.stackexchange.com/questions/69181/what-is-tcp-spoofing
Jedenaście odpowiedzi:
Steve Sether
2017-07-20 19:39:54 UTC
view on stackexchange narkive permalink

Aby wysłać dane do aplikacji przy użyciu protokołu TCP, musisz najpierw nawiązać połączenie. Dopóki połączenie nie zostanie nawiązane, pakiety docierają tylko do warstwy systemu operacyjnego, a nie do aplikacji. Ustanowienie połączenia wymaga odebrania pakietów z powrotem do początkowego końca. Jeśli chcesz sfałszować adres IP spoza własnej sieci i ustanowić połączenie TCP, musisz mieć możliwość przechwytywania pakietów wysyłanych przez drugą stronę. (musisz być „pomiędzy” punktem końcowym i miejscem, do którego zwykle trafiłyby pakiety do sfałszowanego adresu IP, lub wykonać inne sprytne sztuczki routingu.)

UDP nie ma połączenia, więc możesz sfałszować pakiet z dowolnym adresem IP i powinien trafić do aplikacji. Oczywiście nadal nie odzyskasz pakietów, chyba że znajdziesz się we właściwym „miejscu”. To, czy ma to znaczenie, czy nie, zależy od zabezpieczeń, które zastosujesz w aplikacji. Jeśli miałbyś ufać pewnym adresom IP bardziej niż innym w aplikacji, może to stanowić problem.

Zatem w tym sensie TCP jest bardziej „bezpieczny” niż UDP. W zależności od aplikacji może to mieć znaczenie dla bezpieczeństwa lub nie. Samo w sobie nie jest to wystarczający powód, aby zastąpić UDP protokołem TCP, ponieważ między tymi dwoma protokołami występują inne kompromisy.

* „UDP nie ma połączenia, więc możesz sfałszować pakiet z dowolnym adresem IP i powinien on dostać się do aplikacji.” * Czy powinno?Miałem wrażenie, że to mit miejski ze względu na filtrowanie ruchu wlotowego / wylotowego po stronie dostawcy usług internetowych.
@Merhdad Nie.Jest to główny czynnik powodujący problem z atakami DDoS z reflektorem DNS.Filtrowanie ruchu przychodzącego oznacza tylko, że dostawca usług internetowych sprawdza, czy podane źródło pakietu jest zgodne z sąsiadem interfejsu / BGP, przez który przyszedł, a filtrowanie ruchu wychodzącego nie odbywa się tak często, jak byśmy chcieli.
Zgadzam się z @Shadur, i z większością odpowiedzi, z dodaną pochwałą, że „bezpieczniejszy” nie jest z założenia, ale w ten sposób zapewnia pewną ochronę przed spoofingiem, ale nie jest wodoodporny.Widziałbym to podobnie jak np.NAT, żadne z nich nie jest zaprojektowane jako funkcja bezpieczeństwa, ale stwarza przeszkody dla atakujących, którzy muszą przeskoczyć.Właściwe bezpieczeństwo oznaczałoby użycie funkcji uwierzytelniania w protokole UDP lub TCP albo dodanie nagłówków uwierzytelniania (IPsec AH).
Zresztą nie można po prostu arbitralnie zastąpić UDP TPC.Opóźnienia w dostawie w przypadku utraty pakietów, długa konfiguracja połączenia, brak multiemisji ... Wybór protokołu UDP vs TCP nie dotyczy bezpieczeństwa, ale wymagania aplikacji.
sluge
2017-07-20 17:27:21 UTC
view on stackexchange narkive permalink

Podczas czytania prezentacji MS SDL (Microsoft Security Development Lifecycle) znalazłem zalecenie, aby zastąpić UDP w aplikacjach TCP, ponieważ TCP jest bezpieczniejszy niż UDP. Ale obie są tylko warstwami transportowymi, niczym więcej.

Dlaczego więc TCP jest bezpieczniejszy niż UDP?

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (http://chat.stackexchange.com/rooms/70130/discussion-on-question-by-sluge-why-is-tcp-more-secure-than-udp).
domen
2017-07-20 17:46:55 UTC
view on stackexchange narkive permalink

Zwykły UDP nie zachowuje stanu, ma uściski dłoni itp. Oznacza to, że atakujący może z łatwością wysłać sfałszowany pakiet, chyba że istnieją zabezpieczenia na innych warstwach.

Z drugiej strony, wysłanie sfałszowanego pakietu TCP wymaga atakujący odgadnie numer sekwencyjny i port klienta nawiązanego połączenia.

Lub po prostu być w tej samej sieci LAN i zatruwać tablice arp, aby uzyskać całą komunikację, a następnie po prostu zwiększyć sekwencję, gdy chce wstawić pakiet, a to powoduje, że `` prawidłowy '' pakiet zostaje odrzucony jako zła retransmisja ...
Warto zauważyć, że każda w połowie bezpieczna aplikacja powinna sama utrzymywać stan, implementować uzgadnianie itp., Więc dodatkowe funkcje TCP _powinny_ być zbędne.
@Nat warto porównać zawijanie TCP w TLS i nie zauważyć wyższych poziomów uzgadniania z ponownym wdrożeniem IKE, aby mieć bezpieczną interakcję UDP, która może poradzić sobie z utratą uścisków dłoni, co powinno sprawić, że wszystko będzie zbędne.
TheJulyPlot
2017-07-20 17:37:20 UTC
view on stackexchange narkive permalink

TCP nie jest bezpieczniejszy niż UDP, jest bardziej „niezawodny”, ponieważ jest stanowy i wymaga potwierdzenia każdego segmentu. UDP jest bezpaństwowy i po prostu wysyła segmenty bez wiedzy klienta, czy je pobiera, czy nie.

Ani nie ma żadnych niestandardowych funkcji bezpieczeństwa, których nie mają inne, różnice są mizerne ze względu na różne wymagania każdego protokołu, wszelkie postrzegane korzyści związane z bezpieczeństwem są mizernymi produktami ubocznymi protokołów funkcjonalnie, a nie celową funkcją bezpieczeństwa.

EDYCJA: UDP i TCP mają określone zastosowania, żadne z tych zastosowań nie jest związane z bezpieczeństwem.

Oba protokoły opierają się na innych protokołach w celu zapewnienia bezpieczeństwa. Więc chociaż TCP może mieć nieco mniejszą powierzchnię ataku, jest to naprawdę nieistotne, ponieważ aby zabezpieczyć, potrzebujesz protokołu zorientowanego na bezpieczeństwo. Protokół taki jak DTLS lub Google QUIC.

Wybór implementacji TCP w przypadku użycia, który jest lepiej dostosowany do UDP, zamiast prawidłowego zabezpieczania UDP (TCP również wymagałby zabezpieczenia w większości przypadków użycia), wyglądałby tak: używanie żelazka 9 do wkładania, ponieważ uważasz, że żelazko 9 byłoby lepszą bronią do obrony w walce ... kiedy masz broń w kieszeni.

Bezpieczeństwo dzięki szczęśliwemu efektowi ubocznemu to nadal bezpieczeństwo.Może nie jest to * świetne * zabezpieczenie, ale nadal może być * bezpieczniejsze * niż inny przypadek.
Tak, rozumiem ten punkt widzenia.Ale wybór TCP przez UDP jest podjęciem decyzji projektowej na podstawie efektu ubocznego.Osobiście gdybym miał przypadek użycia, który byłby lepiej dostosowany do UDP, użyłbym UDP i zabezpieczyłbym go za pomocą protokołów zaprojektowanych z myślą o bezpieczeństwie.
Ponieważ integirty jest z definicji filarem bezpieczeństwa, a większa powierzchnia ataku UDP polega głównie na atakowaniu integralności poprzez fałszowanie pakietów, więc myślę, że można bezpiecznie powiedzieć, że TCP jest bezpieczniejszy.
@PanosK.Integralność oznacza, że dane są godne zaufania.Nie zapewnia tego proste wykrywanie błędów w TCP.Nie powinien i nie został do tego zaprojektowany.Powiedzenie, że TCP jest bezpieczniejszy niż UDP, to tak, jakby powiedzieć, że Volkswagen jest lepszym samochodem rodzinnym niż Ford, kiedy mówimy o tym, który czołg jest lepszy do działań wojennych.Tak, Volkswagen może mieć 5 gwiazdek, a Ford tylko 4, ale nadal nie jest lepszym czołgiem i nadal nie będzie cię bronił w walce czołgów.
@TheJulyPlot: D Nie mówię, że TCP jest bezpieczniejszy, ale bardziej w ten sposób rozumiem, jak ci goście z MS SDL doszli do tego wniosku.
Zdecydowanie najlepsze wyjaśnienie.
WhiteWinterWolf
2017-07-21 14:14:40 UTC
view on stackexchange narkive permalink

Czy TCP jest bezpieczniejszy niż UDP?

Tak, ale musimy bardzo jasno określić, o czym mówimy, kiedy mówimy o „bezpieczeństwie” i nie uogólniać tego stwierdzenia na protokoły wyższych warstw.

Obecnie bezpieczeństwo jest często kojarzone z triadą CIA :

  • C onfidentiality.
  • I ntegrity.
  • A dostępność.

Wersja 4 protokołu IP, który jest obecnie najczęściej używanym protokołem, to bardzo stara bestia, która została opracowana w latach 70-tych i 80-tych.

W tamtych czasach poufność nie była tak naprawdę tematem i naprawdę była celem miał na celu osiągnięcie integralności i dostępności (sieć Arpanet, przodek Internetu, który dał początek protokołowi IP, została zaprojektowana tak, aby zapewnić ciągłość usług nawet w przypadku wojny nuklearnej, a nie chronić dane w tranzycie).

W tej optyce dwa protokoły transportowe zostały opracowane w warstwie IP: TCP i UDP.

TCP wa to taki, który zapewnia zarówno właściwości integralności , jak i dostępności . Obejmuje to, co w tamtych czasach było zaawansowanymi technikami, takimi jak uzgadnianie trójetapowe, negocjowanie parametrów, obsługa różnych stanów połączenia, przejrzyste zmienianie kolejności pakietów, okna potwierdzeń i mechanizmy ponawiania. Daje to dobre gwarancje dla nadawcy, że dane, które wysłał, zostały odebrane w pełnej, nieuszkodzonej formie (tj. Bez brakujących, zmienionych lub nieuporządkowanych części).

Przypomnijmy, że ten protokół był celem katastrofa techniczna, a nie złośliwa ingerencja w przesyłane dane. Taki problem był wtedy całkowicie poza zakresem.

Wręcz przeciwnie, UDP został zaprojektowany jako szybki protokół. Nie ma żadnej z wyżej wymienionych cech, a zatem nie ma również ich narzutu. W szczególności, gdy nadawca wysyła niektóre dane za pomocą UDP, otrzymane dane mogą być niekompletne, nieuporządkowane lub w ogóle nie odebrane: sam protokół UDP nie zapewnia żadnego mechanizmu zapobiegającego temu ani wykrywającego ani po stronie nadawcy, ani odbiorcy. / p>

W ten sposób, koncentrując się na integralności danych i właściwościach bezpieczeństwa w zakresie dostępności, TCP jest rzeczywiście bezpieczniejszy niż UDP.

Czy protokół aplikacji oparty na TCP jest bezpieczniejszy niż protokół oparty na protokole TCP UDP?

Z pewnością nie.

Oznacza to tylko, że osoby opracowujące protokół aplikacji oparty na UDP będą miały więcej pracy, ponieważ być może będą musiały zaimplementować w swoich aplikacjach obejścia brakujących funkcji. w protokole UDP. Będą musieli wziąć pod uwagę, że wysłane dane mogą niekoniecznie zostać odebrane, że otrzymane dane mogą nie być we właściwej kolejności itp. To wszystko są dobrze znane problemy.

Na przykład OpenVPN, podczas gdy obsługuje TCP głównie ze względu na kompatybilność z restrykcyjnymi zaporami ogniowymi, działa domyślnie i najlepiej działa przez UDP. Przełączenie go na TCP jest możliwe, ale w żaden sposób nie zwiększy jego bezpieczeństwa, ponieważ różnica między protokołami dwóch warstw transportowych UDP i TCP jest w pełni obsługiwana przez sam OpenVPN. Przełączenie go na TCP spowoduje tylko dodanie narzutu TCP do protokołu OpenVPN, zmniejszając w ten sposób jego wydajność.

Czy TCP jest lepszy od UDP?

Nie, jest to całkowicie wybór projektu protokołu aplikacji .

UDP jest protokołem bardziej surowym. Przy prawidłowym i starannym użyciu może osiągnąć lepszą wydajność niż TCP za cenę trudniejszego rozwoju i utrzymania protokołu aplikacji.

  • Gdy aplikacja nie jest na czasie wrażliwy, TCP narzuca się jako naturalny wybór, ponieważ nie ma potrzeby odkrywania koła na nowo.
  • Gdy aplikacja jest wrażliwa na czas, musi nastąpić dyskusja, w której należy wybrać, wiedząc, że każda z nich będzie miała swoją wadę: potencjalny spadek wydajności w przypadku TCP w porównaniu z z pewnością bardziej złożona aplikacja z UDP.

Większość protokołów nie jest wrażliwa na czas i dlatego TCP jest najczęściej używanym protokołem. Rzeczywiście, kiedy ładujesz stronę internetową lub otrzymujesz wiadomość e-mail, nie ma różnicy, czy otrzymasz ją wcześniej czy później 10 milisekund.

Dwa klasyczne przykłady protokołów wykorzystujących UDP, oprócz wspomnianego wcześniej OpenVPN, to media streaming i DNS.

W przypadku strumieniowego przesyłania multimediów nie obchodzi Cię, czy brakuje jednej klatki wideo lub kilku milisekund wideo lub audio, o ile wideo lub dźwięk są odtwarzane płynnie i synchronicznie. W takim przypadku nie chcesz wywoływać powtarzających się przerw, ponieważ TCP wykrył brakujący pakiet i poprosił nadawcę o ponowne wysłanie zawartości ostatniego okna potwierdzenia.

W przypadku DNS żądania i odpowiedzi są zwykle bardzo krótkie i chcesz, aby proces rozpoznawania nazw był jak najszybszy (zwróć uwagę, że dłuższe i mniej wrażliwe na czas odpowiedzi, takie jak transfery stref DNS, zwykle nadal występują na TCP). Szybsze jest ponowne wysłanie żądania rozwiązania nazwy do serwera DNS przy bardzo niewielu przypadkach utraty żądania lub odpowiedzi niż przetwarzanie pełnoprawnego potrójnego uzgadniania dla każdego żądania.

A co z poufnością i złośliwe podsłuchiwanie / manipulowanie (i IPv6)?

Do tej pory zależało nam tylko na tym, w duchu starego protokołu IPv4, równowadze między szybkością transmisji a integralnością danych + dostępnością. Teraz, jeśli chcemy dodać do tego poufność, możemy to zrobić, ale będzie to musiało być zrobione w warstwie aplikacji, ponieważ, jak wspomniano wcześniej, IPv4 nie dotyczy kwestii poufności.

Nowoczesną, pełnoprawną implementację zabezpieczeń można zaimplementować w warstwie aplikacji i polegać na protokołach TCP lub UDP (lub obu) bez żadnego wpływu na bezpieczeństwo samego protokołu aplikacji (patrz przykład OpenVPN powyżej).

Jednak, jak stwierdzono na początku, IPv4 naprawdę pochodzi z innej epoki komputerowej. Otrzymał następcę o nazwie if IPv6, który natywnie obsługuje IPSec w warstwie IP, zapewniając w ten sposób bardziej nowoczesne usługi bezpieczeństwa poniżej protokołów transportowych, takich jak UDP i TCP.

Umożliwia to delegowanie szyfrowania danych w trakcie przesyłania z aplikacji do warstwy sieciowej i umożliwia zarówno protokołom UDP, jak i TCP zapewnienie dokładnie takich samych gwarancji bezpieczeństwa. Jednak w większości scenariuszy wzrost wydajności UDP będzie równoważony przez narzut IPSec, więc nie jestem pewien, czy korzystanie z UDP zamiast TCP przyniesie jakąkolwiek korzyść, o ile używany jest IPv6 IPSec.

Joshua Faust
2017-07-20 18:12:40 UTC
view on stackexchange narkive permalink

Protokół TCP jest „oparty na połączeniach”, co oznacza, że ​​ma wbudowaną niezawodność w postaci numerów sekwencyjnych. Na przykład wysyłam obraz przez TCP, ale 1/4 pakietów zostaje odrzuconych. Ponieważ mamy protokół oparty na połączeniu z numerami sekwencyjnymi, Twój komputer będzie wiedział, że brakuje ci tych danych i dlatego zażąda ode mnie tych danych, aby zachować integralność danych. Jest to wolniejsze, ale znacznie bezpieczniejsze. Ponadto, aby sfałszować pakiety TCP / IP, musisz przechwycić ten numer sekwencyjny i wysłać złośliwy pakiet. Bez człowieka w środku jest to prawie niemożliwe!

UDP jest protokołem „bez połączenia”, co oznacza, że ​​po prostu wysyła dane i zapomina. Nie ma niezawodności ani integralności danych, ale w niektórych aplikacjach jest to szybsze i bardziej wydajne.

To nie jest niemożliwe, aby zalać maszynę pakietami tcp syn / ACK / syn-ACK ... przechwycenie jest trudniejsze, ale sekwencję można odgadnąć przez węszenie po zatruciu arp na przykład (nie w Internecie, ale w sieci lokalnej jednej ze stron).Więc nie ma prawdziwego dodatkowego bezpieczeństwa jako takiego.
Nadal uważałbym to za bezpieczniejsze, ponieważ kroki mające na celu złamanie zabezpieczeń TCP, który przechowuje bardziej wartościowe dane, są trudniejsze i uciążliwe.Zasadniczo musisz złamać zabezpieczenia sieci, skonfigurować MiTM przez zatruwanie ARP, a następnie (być może) zatruwanie DNS, i stamtąd być w stanie wstrzyknąć wszystko, co przepływa przez ciebie cały ruch, „Fałszywa brama”.Możesz też po prostu skonfigurować fałszywy AP i czekać, aż ludzie się połączą, co jest o wiele łatwiejsze haha.Tak czy inaczej, przechwytywanie TCP = hakowanie z większą liczbą kroków, podczas gdy przechwytywanie UDP = hakowanie.lol
jeśli celem jest wysłanie pakietu w imieniu oryginalnego użytkownika, wystarczy odpowiedzieć na żądanie arp bramy po stronie użytkownika lub serwera docelowego po stronie serwera, aby uzyskać kopię pakietów do odgadnięcianumer kolejny.To tylko jeden krok więcej niż udp.Jeśli chcesz dwukierunkowy, tak, musisz uzyskać jako MITM, ale dotyczy to również UDP.Dodatkowe zabezpieczenia są bardzo małe
rackandboneman
2017-07-21 13:53:48 UTC
view on stackexchange narkive permalink

W praktyce protokół TCP jest łatwiejszy do nadzorowania w sieci z zaporą ogniową: ruch związany z połączeniami nawiązanymi zewnętrznie i wewnętrznie, a zatem rolami klienta i serwera, można wyraźnie rozróżnić i obsługiwać za pomocą oddzielnych zasad. Na przykład można w trywialny sposób zapewnić, że hosty w chronionej sieci będą miały dostęp do zewnętrznego serwera WWW, ale nie będą mogły działać jako serwer WWW dla klientów zewnętrznych. W przypadku usług UDP (na przykład DNS) egzekwowanie takich zasad wymaga znacznie większej inteligencji i domysłów, ponieważ musisz wziąć pod uwagę informacje powyżej i poniżej warstwy transportowej.

Arnaud Bouchez
2017-07-24 13:12:12 UTC
view on stackexchange narkive permalink

TCP nie jest „bezpieczniejszy” niż UDP:

  • TCP nie ma funkcji szyfrowania per se ;
  • Transmisja pakietów TCP jest niezawodna , ale możesz emulować to samo przez UDP.

UDP to tylko cienka warstwa na wierzchu pakietów IP, podczas gdy TCP ma złożone - i standardowe - dodatkowe mechanizmy, które są częścią Systemy operacyjne.

Warto przyjrzeć się projektowi QUIC, aby dowiedzieć się więcej o różnicach między protokołami TCP / UDP i dlaczego Google stworzył własną zabezpieczoną warstwę transportową HTTP / 2 przez UDP zamiast TCP.

Cytujmy https://www.chromium.org/quic:

Kluczowe zalety QUIC w porównaniu z TCP + TLS + HTTP2 obejmują:

  • Opóźnienie ustanowienia połączenia
  • Ulepszona kontrola przeciążenia
  • Multipleksowanie bez blokowania nagłówka linii
  • Poprawianie błędów w przód
  • Migracja połączenia
Shaboti
2019-11-30 09:50:29 UTC
view on stackexchange narkive permalink

Ustawmy kilka zalet / wad perspektyw bezpieczeństwa dla każdego z nich i zobaczmy:

UDP

  • (+) Stosunkowo trudny do skanowania UDP otwarte porty i nie istnieje żadne ukryte skanowanie (połowa połączenia w TCP przez wysłanie SYN).
  • (-) Urządzenia sieciowe (np. stanowe zapory ogniowe, NAT) mają problemy z kontrolą połączeń UDP, ponieważ nie ma FLAG, na których można by polegać na.
  • (-) Ataki odbite są częstsze z powodu braku połączenia.
  • (-) Spoofing IP jest łatwy i używany w ataku DoS.

TCP

  • (-) Stealthy scan może wykryć otwarte porty TCP (wyślij SYN tylko w celu wykrycia otwartych portów)
  • (+) Urządzenia sieciowe (np. Stanowe zapory ogniowe) mogą łatwo śledzić i kontrolować połączenia TCP.
  • (+) Fałszowanie pakietów nie jest łatwe, ponieważ wymaga podania prawidłowego numeru sekwencyjnego i numeru potwierdzenia.
  • (+) Sfałszowanie adresu IP nie jest tak łatwe jak UDP ze względu na początkowy uścisk dłoni.
morris hoodye
2017-07-21 08:26:47 UTC
view on stackexchange narkive permalink

Obecnie protokół TCP nie jest bezpieczniejszy niż UDP. TCP jest bardziej niezawodny niż UDP, ponieważ TCP może wykrywać i retransmitować pakiety błędów.

Jeśli ktoś chce mieć bezpieczną transmisję danych, rozważa użycie szyfrowania w jakimś formacie, takim jak TLS lub IPSec.

David Trott
2017-07-22 23:08:20 UTC
view on stackexchange narkive permalink

TCP opiera się na koncepcji połączenia, natomiast UDP nie. Jednak koncepcja połączenia jest zarówno mocną, jak i słabą z punktu widzenia bezpieczeństwa. Główną siłą bezpieczeństwa połączenia jest to, że jest ono ustandaryzowane, twórca aplikacji, sprzęt sieciowy i zapory ogniowe mogą polegać na ustalonej metodzie nawiązywania połączenia, obsługi fragmentacji pakietów, retransmisji i tak dalej. Dodatkowo koncepcja połączenia ułatwia budowanie dodatkowych warstw bezpieczeństwa na wierzchu, na przykład SSL.

Jednak połączenie TCP nie zapewnia zbytniej ochrony przed atakiem, który jest bezpośrednio skierowany na warstwę transportową, na przykład Atak SYN Flood. Dzięki UDP teoretycznie można uwierzytelnić każdy pakiet, aby złagodzić niektóre z tych zagrożeń.

Dlatego uważałbym, że UDP jest „teoretycznie” bezpieczniejszy niż TCP, jednak żyjemy w świecie, w którym bezpieczeństwo nie jest doskonałe, więc teoretyczna siła jest nieco bez znaczenia. W prawdziwym świecie można znaleźć przykłady w obie strony - gdzie jeden protokół zawiódł w taki sposób, że drugi nie byłby podatny.

Podsumowując, nie sądzę, aby istniała odpowiedź do tego, który protokół jest bardziej „bezpieczny”, musisz zakwalifikować swoje pytanie do tego, jakich zagrożeń jesteś zaniepokojony oraz ile i jak długo jesteś skłonny poświęcić na ich złagodzenie. Jeśli to wszystkie zagrożenia, a masz nieskończoną ilość czasu i pieniędzy, moja teoretyczna odpowiedź jest aktualna.

[UDP też ma ataki typu flooding] (https://www.juniper.net/documentation/en_US/junos12.1x44/topics/concept/denial-of-service-network-udp-flood-attack-understanding.html).Twoja odpowiedź wymaga większego wsparcia, dlaczego UDP jest „teoretycznie” bezpieczniejszy niż TCP.
@user2320464 Dziurę rfc792 można zamknąć, nigdy nie wysyłając pakietu „miejsce docelowe nieosiągalne”. Istnieje również wiele asymetrycznych ataków na usługi oparte na UDP;ale ja po prostu traktuję to jako lukę w aplikacji (lub protokół, który aplikacja implementuje, DNS, ntp,… itd.). Odetchnąłem z problemem z TCP (konieczność alokacji zasobów po otrzymaniu pierwszego pakietu).Proszę zwrócić uwagę na jakąkolwiek lukę na poziomie protokołu (niezwiązaną z aplikacją i implementacją) w UDP, która nie dotyczy również TCP i której nie można zamknąć w naszym teoretycznym świecie.


To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...