SS is het origineel, SSR is een derde partij versie afgeleid van het origineel, compatibel met het oorspronkelijke protocol en heeft meer camouflagefuncties (protocol en verwarring) dan het origineel.
Er is ook veel discussie over SSR op het internet, zowel voor als tegen, maar voor gewone gebruikers. Of het nu SS of SSR is, het kan je nu helpen om normaal over de muur te klimmen.
Wat betreft welke versie van de client je downloadt, hangt het er helemaal vanaf of SS of SSR is geïnstalleerd op de server van het SS-account dat je hebt gekocht. De meest originele SS-functie kan worden gebruikt ongeacht welke client wordt gedownload, maar als je de functies van SSR wilt gebruiken (protocol en verwarring), moet je de SSR-client downloaden.
Maar maak je geen zorgen, alle nodes die we aanbieden ondersteunen SS- en SSR-compatibiliteit. Het wordt aanbevolen om SSR te gebruiken. Sneller om te voorkomen dat je geharmoniseerd wordt!
Er was veel ophef over Shadowsocks enige tijd geleden, en onlangs is het duidelijk dat veel beginners zich aangetrokken voelen tot de zogenaamde "Shadowsocks Enhanced" (ShadowsocksR). Als amateurontwikkelaar van het implementeren van Shadowsocks in C++/Qt, wil ik kort mijn mening geven over deze twee gefrituurde kippen.
ShadowsocksR
Ik weet niet of de ontwikkelaar erachter een achtergrond heeft of een team, maar wat ik wel weet is dat de maker de Shadowsocks C#-client heeft gesloten als close source voor de secundaire ontwikkeling, in strijd met de GPL. We zullen het hier niet over andere factoren hebben, het feit is dat de GPL heel duidelijk is zwart-wit, schenden is schending zijn. Maar de auteur maakte vervolgens de codebase open source, wat kan worden gezien als het einde van een incident, en er is geen noodzaak om het verder te onderzoeken.
De zaken veranderden nadat Clowwindy zijn Shadowsocks-codestore leegmaakte. Hieronder volgt slechts een lijst van feiten:
De auteur van ShadowsocksR heeft gezegd dat hij helemaal opnieuw wil beginnen met het schrijven van een nieuwe proxytool die niet gerelateerd is aan shadowsocks, en dat hij ShadowsocksR niet langer zal updaten
Twee of drie dagen later werd ShadowSocks bevolen te verwijderen en verdween het oorspronkelijke Shadowsocks-project vrijwel
De auteur van ShadowsocksR zei dat het oorspronkelijke shadowsocks-protocol gebrekkig was (besproken in de volgende sectie) en kwam weer in focus.
De auteur van ShadowsocksR heeft een Google+ Group opgericht en de ShadowsocksR-gerelateerde code bijgewerkt
Shadowsocks beveiliging
Laten we nu beginnen met de beschrijving van de bewering van de ShadowsocksR-auteur dat het Shadowsocks-protocolfout is dat de lengte van de IV in de meeste gevallen 16 bytes is. De tweede helft klopt, veel encryptie-algoritmen gebruiken IV's van 16 bytes (vooral de populaire AES en RC4-MD5), en wat dan nog? Dit introduceert geen zogenaamde "defecten" om de volgende redenen:
De IV van elke TCP-verbinding bij de handdrukfase wordt willekeurig gegenereerd en niet berekend uit het wachtwoord, waardoor de IV onvoorspelbaar is.
Zonder de sleutel kan de ciphertext zelfs als dit deel van de IV wordt onderschept, niet worden ontsleuteld. En elke nieuwe TCP-verbinding gebruikt een willekeurig gegenereerde IV, dat wil zeggen, de data die van verschillende TCP-verbindingen wordt onderschept heeft weinig gemeen. Het ontsleutelen van ciphertext vereist zowel de juiste IV als de cipher, en elke verbinding heeft geen kenmerken van de cipher.
De meeste IV's zijn 16 bytes lang, wat een mogelijke combinatie is van 256 tot de macht van 16, en het is onmogelijk om brute force crack te maken als alle IV's hetzelfde zijn, laat staan om een tweede punt toe te voegen.
Volgens de aanpak van ShadowsocksR is het nutteloos om de zogenaamde obfuscatieheader toe te voegen vóór de eerste verbinding, zijn de eigen kenmerken duidelijk, en het verandert de essentie van de latere IV of vaste lengte helemaal niet. Omdat de vierde byte je de lengte van de willekeurig ingevulde data aangeeft, kun je, zolang je de vorige stapel overslaat bij het zogenaamde "probing", IV nog steeds onderscheppen. En zoals ik een paar punten geleden al zei, is het nutteloos als je zomaar een infuus krijgt. Als het wordt gebruikt voor detectie, is de vaste eerste versie van het logo het naakte kenmerk dat ter identificatie wordt gestuurd.
De auteur van ShadowsocksR biedt momenteel een active detection script dat kan worden gebruikt om te detecteren of de server shadowsocks draait, en volgens de huidige online testrapporten is het slagingspercentage niet laag (maar niet 100%). In dit opzicht heeft Clowwindy in de originele versie al een automatische ban-oplossing gegeven, waarbij deze kwaadaardige IP's automatisch worden geblokkeerd. Ik heb net een patch toegevoegd aan libQtShadowsocks en deze patch blokkeert de detectie van deze methode, die willekeurige strings van willekeurige lengte teruggeeft volgens willekeurige waarschijnlijkheid.
Dit betekent echter niet dat het Shadowsocks-protocol perfect is, maar dat de "oplossing" van ShadowsocksR scheef is omdat de focus scheef is. Mijn persoonlijke idee is om publieke sleutels en private keys te gebruiken om de beveiliging te verbeteren, hoewel het niet erg vriendelijk is voor beginners, maar de beveiliging zal verbeteren en de eigenschappen zullen worden verminderd (geen IV's nodig bij de handdrukfase), en het shadowsocks-protocol moet zich ontwikkelen in de richting van CCA-beveiliging.
Bijgewerkt 05-sep-2015
Zodra de headerfout (die niet kan worden opgelost) is gevonden, worden de verkeerde IV en IP toegevoegd aan de lijst met mislukte IV en IP; als de IV al in de mislukte IV-lijst staat, of het IP al in de lijst met mislukte IP's, wordt het IP dat het verbindingsverzoek heeft verzonden aan de zwarte lijst toegevoegd en zal het IP in de zwarte lijst de verbinding direct weigeren. Voor de laatste details over anti-detectie, raadpleeg dit probleem, en dit artikel zal de tegenmaatregelen voor anti-detectie niet bijwerken.
Bijgewerkt 06-sep-2015
Dit artikel wil je alleen vertellen dat je je niet te veel zorgen hoeft te maken over de beveiliging van Shadowsocks, het huidige protocol heeft nog geen grote kwetsbaarheden en de servers van de hoofdpoorten worden ook bijgewerkt om potentiële bedreigingen op te lossen. Ik heb ook goed gecommuniceerd met de auteur van ShadowsocksR, en het zal nog wel even duren voordat de whitelist arriveert.
Bijgewerkt op 24-sep-2015
De Shadowsocks-beveiliging die in dit artikel wordt genoemd, verwijst meer naar de beveiliging van de server, en het huidige protocol brengt het risico met zich mee dat de server wordt blootgesteld aan brute force-detectie en vervolgens wordt geblokkeerd door firewalls (hoewel de detectiekosten erg hoog zijn). De beveiliging van de verzonden inhoud is niet om zich zorgen over te maken, dit zijn allemaal industriële hoogwaardige encryptie-algoritmen (behalve RC4 en TABLE), en het is vrijwel onmogelijk om de verzonden inhoud te kraken.
Bijgewerkt op 18-nov-2015
Shadowsocks heeft zijn beveiliging tegen CCA verbeterd door één enkele verificatie toe te voegen, en grote havens hebben hun ondersteuning al afgerond. Het is belangrijk om te herhalen dat het doel van Shadowsocks niet is om 100% bugvrij of 100% kogelvrij te zijn, maar om ervoor te zorgen dat de verbinding licht en snel is, terwijl de gangbare aanvalsmethoden te duur zijn om te implementeren.
|
Geplaatst op 10-11-2017 12:41:35
|
|
|
