Beveilig je connecties met SSH

ArticleCategory:

System Administration

AuthorImage:

Bernard Perrot

TranslationInfo:[Author and translation history]

original in fr Bernard Perrot  

fr to en Guy Passemard  

en to nl GH Snijders  

AboutTheAuthor

Bernard is System en Netwerk Enigneer voor het CNRS (Frans Nationaal wetenschappelijk onderzoek centrum) sinds 1982. Hij heeft de leiding gehad over projecten met betrekking tot computer systeem beveiliging bij het "Institut National de Physique Nucléaire et de Physique des Particules" (In2p3). Tegenwoordig is hij werkzaam bij het Instute Of Mathematical Research (IRMAR) in het Natuurkundig en mathematische wetenschappen departement (SPM).

Abstract

Dit artikel werd voor het eerst gepubliceerd in een speciale editie van Linux Magazin Frankrijk, gefocust op beveiliging. De redacteur en de autheurs waren zo vriendelijk om LinuxFocus toe te staan om ieder artikel uit deze speciale uitgave te publiceren. Aansluitend, zal LinuxFocus deze presenteren zodra de vertaling naar het Engels gereed is. Met dank aan alle mensen die betrokken zijn bij dit werk. Deze abstract zal gereproduceerd worden voor artikelen van dezelfde oorsprong.

In dit artikel zullen we een goede blik werpen op SSH, en op het gebruik ervan. Dit is geen gids of installatie handleiding, maar eerder een introductie in het vocabulair en de mogelijkheden van SSH. De links en documentatie bij dit artikel zullen alle implementatie details bezorgen.

ArticleIllustration:

ssh

ArticleBody:[The article body]

Waar wordt SSH voor gebruikt?

Allereerst (en historisch), SSH (het commando ssh is een veilige variant van de rsh en rlogin commando's. SSH staat voor "Secure SHell" zoals rsh staat voor "Remote SHell". Dus, zoals rsh je eenvoudig toegang kan geven tot shell op een andere machine, zonder mechanisme voor gebruikers authenticatie, levert SSH dezelfde mogelijkheid maar dan met een hoog niveau van beveiliging.

Als we erg kort door bocht zouden willen zijn voor een gebruiker die niet meer wil weten (of doen), zouden we hier kunnen stoppen en zeggen dat de beheerder z'n werk heeft gedaan en de software heeft geïnstalleerd (dit is tegenwoordig simpel), en dat alles wat je nodig hebt, het SSH commando is, om het telnet, rsh of rlogin commando's te vervangen en dat alles hetzelfde werkt met betere beveiliging.

Dus, als je gebruik maakte van:

% rlogin serveur.org (of telnet serveur.org)

gebruik je nu:

% ssh serveur.org

en het is nu al een stuk beter!

Ter afsluiting van deze korte samenvatting, wil ik stellen dat vanaf vandaag, alle beveiligings incidenten die voorkomen konden worden door simpelweg SSH te gebruiken in plaats van rsh (rlogin, telnet) voornamelijk een consequentie zijn van nalatigheid van het slachtoffer.

Benodigdheden

Om meer informatie te geven, volgen hier een paar van de meest cruciale en fragiele aspecten van interactieve connecties die men graag opgelost ziet:

Als reactie op deze eisen, bestaan er oplossingen die niet echt bevredigen:

En er is SSH, een goede oplossing voor:

SSH versie 1 en SSH versie 2

Niets is perfect in deze wereld, daarom bestaan er twee niet-compatibele versies van het SSH protocol: de 1.x versie (1.3 en 1.5) en de 2.0 versies. Om te switchen van de een naar de ander is geen probleem voor de gebruiker, mits met de juiste client en de juiste server bij de hand.

Het SSH versie 1 protocol is geïntegreerd, waar SSH versie 2 het vorige protocol heeft geherdefiniëerd in drie "lagen" (layers):

  1. SSH Transport Layer Protocol (SSH-TRANS)
  2. SSH Authentication Protocol (SSH-AUTH)
  3. SSH Connection Protocol (SSH-CONN)

iedere laag is specifiek gedefiniëerd in een document (draft) genormaliseerd door de IETF, gevolgd door een vierde draft, welke de architectuur (SSH Protocol Architecture, SSH_ARCH) beschrijft. De details zijn te vinden op: http://www.ietf.org/html.charters/secsh-charter.html

Zonder al teveel op details in te gaan, hier is wat je kunt vinden in SSHv2:

Belangrijke technische verschillen tussen SSH versie 1 en 2 zijn:

SSH versie 1

SSH versie 2

monolitisch (geïntegreerd) ontwerp

scheiding van de authenticatie, connectie en transport functies in lagen

integriteit via CRC32 (niet erg veilig)

integriteit via HMAC (hash encryptie)

een, maar dan ook echt een kanaal per sessie

onbeperkt aantal kanalen per sessie

onderhandeling via symmetrische codering in het kanaal, sessie identificatie met een unieke sleutel aan beide kanten

gedetailleerde onderhandeling (symmetrische codering, publieke sleutels, compressie, ...), en een aparte sessie sleutel, compressie en integriteit aan beide kanten

alleen RSA voor het publieke-sleutel algorithme

RSA en DSA voor publieke-sleutel algorithme

sessie sleutel verstuurd door client

sessie sleutel overeengekomen door Diffie-Hellman protocol

sessie sleutel geldig gedurende de sessie

vernieuwbare sessie sleutel

Een aantal sleutels onderhouden

SSH sleutel typen, laat me ze kort definiëren:

De user voegt een wachtzin (pass phrase) toe, welke de prive sleutel beveiligt, als onderdeel van bovengenoemde sleutels. Deze beveiliging wordt gegarandeerd door het bestand met de prive sleutel te versleutelen met een symmetrisch algortihme. De geheime sleutel die gebruikt wordt om het bestand te versleutelen, komt voort uit de pass phrase.

Authenticatie methodes

Er bestaan verschillende methodes voor de identificatie van gebruikers. De keus wordt gemaakt aan de hand van de eisen, zoals beschreven in de beveilgings policies. De geauthoriseerde methoden worden al dan niet geactiveerd in het configuratie bestand van de server. Hier zijn de principe categorieën:

Het kan ook handig zijn om te weten dat er tenminste nog twee elementen bestaan met betrekking op authenticatie:

De encryptie algorithmes

Er is een verschil tussen degene om communicatie kanalen te versleutelen (encryptie met geheime sleutels) en die voor authenticatie (encryptie met publieke sleutels).

Voor authenticatie kunnen we kiezen tussen RSA en DSA met versie 2 van het protocol, en alleen RSA voor versie 1 (geen keus dus...). Historisch werd DSA gekozen, daar RSA in sommige landen gepatenteerd was. Sinds het eind zomer van het jaar 2000 is RSA vrij van rechten, en dus is deze noodzaak verdwenen. Ik heb werkelijk geen voorkeur voor wat de goede of slechte keus is (alleen dat DSA een "puur" NSA produkt is).

Voor symmetrische encryptie is er bijna teveel om uit te kiezen... Het protocol bevat een algemeen algorithme dat aanwezig moet zijn in alle implementaties: triple-DES met 3 sleutels. Aansluitend zal deze gebruikt worden als de onderhandeling tussen client en server faalt over een ander algortithme. Als je kunt, probeer te onderhandelen met een ander algorithme dan 3DES, daar deze ondertussen een van de minst presenterende algorithmes is. Niettemin zullen we, tenzij noodzakelijk, de exotische of oudere aan kant zetten (arc4, DES, RC4, ...) en ons beperken tot:

Persoonlijk vraag ik me af wat het nut is om zoveel algorithmes voor te stellen: zelfs als het protocol toestaat om een "prive algorithme" te gebruiken (voor een bepaalde groep gebruikers, bijvoorbeeld), lijkt me dit essentieel, maar voor normaal gebruik, zal denk ik, met de tijd, AES de standaard worden. Als AES wordt gekraakt zullen de beveiligingsproblemen groter zijn dan die, die door SSH veroorzaakt worden...

Port Forwarding, tunnelen

SSH staat toe om een willekeurige TCP data stroom om te leiden (forwarding) door een "tunnel" in een SSH sessie. Dit betekend dat de applicatie data-stroom, in plaats van direct door de client en de server poorten te worden beheerd, "ingepakt" wordt in een "tunnel", gecreëerd tijdens connectie (sessie) tijd. (zie ook het volgende diagram

Voor het X11 protocol gaat dit zonder byzondere handelingen door de gebruiker in z'n werk, met transparante afhandeling van de displays (schermen) en staat continue aankondigingen toe, zelfs als ze worden gemaakt via meerdere hops.

Voor andere stromen is er een commando-regel optie, voor iedere kant:

Deze krachtige feature heeft wel eens voor gezorgt dat SSH de "tunnel voor de armen" werd genoemd. Men moet hier wel bedenken dat hier met de "armen" de gebruikers worden bedoeld die geen administratieve rechten hebben op de client zijde. Alleen in bepaalde gevallen kan een lokale poort worden geforward met lagere rechten (poort > 1024) en zonder super-user rechten ("root"). Aan de andere kant, wanneer een geprivileergde poort lokale poort doorgestuurd dient te worden, moet het ofwel met een root account gebeuren, of de client moet voorzien worden van super-user privileges ("suid") (in feite staat een geprivileergde lokale poort een herdefinitie van een standaard service toe).

Zoals alles met IP is het eenvoudig om iets in iets anders te plaatsen (en andersom), het is niet alleen mogelijk om standaard TCP stromen door te sturen, maar ook PPP connecties, welke ons toestaan een "echte" IP tunnel in IP te maken (versleuteld, dus veilig). De methode valt buiten het bereik van dit artikel, maar je kunt de "Linux VPN-HOWTO" lezen voor meer details en setup scripts (er bestaan ook 'native' VPN oplossingen voor Linux, zoals "stunnel" welke je zou moeten bekijken alvorens een beslissing te nemen).

Onthoud dat de eerste mogelijkheid is om telnet stromen om te leiden: dit lijkt volledig nutteloos, daar SSH interactieve verbindingen standaard implementeerd. Echter, met behulp van het doorsturen van telnet verbindingen, kun je je favoriete client blijven gebruiken in plaats van de SSH interactieve modus. Vooral in een Windowstm of MacOstm omgeving kan dit van pas komen, waar de SSH client de ergonomie van de gebruiker niet echt tegemoet komt. Bijvoorbeeld, het "terminal emulatie" deel van de "Mindterm client (Java's SSH client, beschikbaar voor alle moderne systemen) lijdt aan het gebrek aan performance van de Java taal: het kan voordelig zijn om deze client alleen te gebruiken om de SSH tunnel te openen.

Op dezelfde manier, kun je ook een client op afstand starten, zoals een "xterm" (met behulp van de automatische X11 forwarding in SSH), welke ons toestaat SSH te gebruiken op X terminals.

Merk op dat de tunnel openblijft, zolang er data doorheen gaat, zelfs als dit niet van de client komt. Dus, het "sleep" commando wordt erg bruikbaar om een SSH te openen om een nieuwe TCP connectie door te sturen.

% ssh -n -f -L 2323:serveur.org:23 serveur.org sleep 60

% telnet localhost 2323

... welkom bij serveur.org ...

De eerste regel opent de tunnel, start het commando "sleep 60" op de server, en stuurt de lokale poort 2323 naar de (telnet) poort nummer 23 op serveur.org. De tweede start een telnet client op de lokale poort 2323 en zal dan de (versleutelde) tunnel gebruiker met de telnetd daeon op de server verbinden. Het "sleep" commando stopt na een minuut (er is een wachttijd van een minuut om de telnet client te starten), maar SSH zal de tunnel pas afsluiten als de laatste client klaar is.

Belangrijkste distributies: vrij beschikbaar

We moeten onderscheid maken tussen clients en/of servers op de verschillende platformen en je zou moeten weten dat SSH versie 1 en SSH versie 2 niet compatibel zijn. Aan het eind van het artikel, zijn in de referenties andere implementaties met voldoende stabiele features te vinden, die niet in de volgende tabel zijn opgenomen.

produkt

platform

protocol

link

opmerking

OpenSSH

Unix

versies 1 en 2

www.openssh.com

details onder

TTSSH

Windowstm

versie 1

www.zip.com.au/~roca/ttssh.html

 

Putty

Windowstm

versie 1 en 2

www.chiark.greenend.org.uk/~sgtatham/putty

alleen beta

Tealnet

Windowstm

versie 1 en 2

telneat.lipetsk.ru

 

SSH secure shell

Windowstm

versies 1 en 2

www.ssh.com

vrij voor niet-commercieel gebruik

NiftytelnetSSH

MacOStm

versie 1

www.lysator.liu.se/~jonasw/freeware/niftyssh/

 

MacSSH

MacOStm

versie 2

www.macssh.com

 

MindTerm

Java

versie 1

www.mindbright.se

v2 nu commercieel

Merk op dat MindTerm zowel een onafhankelijke implementatie in Java is, (je hebt alleen een Java runtime nodig) als een servlet dat uitgevoerd kan worden in een goed ontworpen, compatible Web browser. Helaas zijn de laatste versies van deze geweldige distributie kort geleden commerciële producten geworden.

OpenSSH

Tegenwoordig is dit waarschijnlijk de distributie om te gebruiken in een Unix/Linux omgeving (continue ondersteuning, goede respons tijden, open source en vrij).

De ontwikkeling van OpenSSH begon met de originele versie (SSH 1.2.12) van Tatu Ylonen (de laatste echt vrije) in het OpenBSD 2.6 project (via OSSH). Tegenwoordig wordt OpenSSH ontwikkeld door twee groepen, een die alleen voor het OpenBSD project ontwikkeld, en een die de code continu aanpast om een portable ("draagbare") versie te maken.

Dit alles heeft z'n consequenties, vooral daar de code steeds meer en meer een monster aanpassing wordt (ik voel het "sendmail" syndroom aan de horizon verschijnen, dit is niet erg gunstig voor een applicatie is gericht op encryptie die extreem rigoreus zou moeten zijn).

Behalve schoon en leesbare coden, ergeren twee andere punten me:

In mijn opinie (en ik ben hier niet alleen in), zou een multiplatform encryptie product een gedemonstreerd, vastgesteld en constant gedrag moeten vertonen, op welk platform het ook draait, als ook rekening houden met de specifieke karakteristieken en de evolutie van het platform en/of deze elimineren.

Dit gezegd te hebben, we moeten toegeven dat de concurrerende implementaties noch veel, noch aantrekkelijk zijn. Ik geloof dat het pragmatischer is om vandaag de dag OpenSSH als de beroerdste implementatie te zien, en de andere buiten spel te houden ...! Een bruikbaar project voor de gemeenschap zou zijn om de code te herontwerpen en te herschrijven.

Slecht nieuws ...

SSH is niet perfect! Waar het voor is gemaakt, doet het goed, maar je kunt niet vragen om meer. Met name zal het geen "ongeauthoriseerde" connecties voorkomen: als een account wordt gecompromitteerd, is het mogelijk voor de inbreker om zichzelf via SSH met je computer te verbinden, zelfs al is het de enige manier, daar hij de authenticatie controleerd. SSH is alleen volledig betrouwbaar als het wordt gebruikt in combinatie met een praktisch en coherent beveiligings beleid: Als iemand overal hetzelfde wachtwoord gebruikt, en niet overal gebruik maakt van SSH, wordt het potentiële beveiligings risico slechts licht minder. Je kunt toegeven dat SSH in dit geval gas tegen kan gaan geven, daar de inbreker een beveiligde, versleutelde verbinding met tunneling kan gebruiken, en zo in staat is om bijna alles te doen wat hij wil, zonder de mogelijkheid om hem op te sporen.

In dezelfde stijl, zou men ook rekening moeten houden met goed ontworpen "rootkits" welke vaak een SSH daemon bevatten om een discrete toegang tot het systeem mogelijk te maken, maar met een paar modificaties: hij luistert niet op poort 22 natuurlijk, heeft de eigenschap om niet te loggen, doet zich voor als doodgewone daemon (bijvoorbeeld httpd) en is onzichtbaar voor een "ps" commando (ook aangepast door de rootkit).

Aan de andere kant moet men zich ook niet te druk maken over het gevaar dat een SSH daemon, die inbrekers toestaat nog verder verborgen te worden, oplevert: je weet (hopelijk) dat het mogelijk is om bijna alles in alles te stoppen in IP, inclusief "wangedrag" van de meest belangrijke protocollen en door een firewall heen: HTML tunneling, ICMP tunneling, DNS tunneling ... Schakel je systeem dus niet in als je een 100% veilig systeem wilt ;-).

SSH is geen uitzondering als het gaat om beveiligings "loopholes", overgenomen van de implementatie (vele zijn in het verleden gecorrigeerd maar perfecte programmatuur bestaat niet), maar ook op protocol niveau. Deze "loopholes" worden nogal alarmerend aangekondigd, maar behelsen meestal zwakheden die technisch zo complex zijn, dat ze lastig zijn te misbruiken: men moet in gedachten houden dat veel beveiligings incidenten die dagelijks voorkomen, vaak voorkomen hadden kunnen worden door het gebruik van SSH en dat diegenen die door SSH worden veroorzaakt door zwakke punten in SSH vaak nogal theoretisch zijn. Het kan interessant zijn om de volgende studie over "man in the middle aanvallen te lezen: http://www.hsc.fr/ressources/presentations/mitm/index.html. Niettemin is het nodig om rekening te houden met deze potentiële zwakke punten voor "high security" applicaties (bankieren, militaire toepassingen ...), waar de bedoelingen van de cracker zeer gemotiveerd zijn door de mogelijke beloning(en).

Ook mag ik graag wijzen op de onmiskenbare zwakeheid van het protocol voor wat betreft de "padding" (opvulling, ook bekend als bedekt kanaal): in zowel versie 1 als 2 hebben de pakketten een lengte die een veelvoud is van 64 bits, en worden opgevuld met een random nummer. Dit is nogal uitzonderlijk, en leidt daardoor tot een klassieke fout die goed bekend is in encryptie producten: een "verborgen" (of subliminaal") kanaal. Meestal vullen we op met een bekende volgorde, als voorbeeld, geef de waarde n aan de byte positie (zelf beschrijvend opvullen). In SSH, met de (per definitie) random volgorde, kan het niet worden gecontroleerd. Daardoor is het mogelijk dat een of meer partijen de communicatie misbruiken, bijvoorbeeld gebruikt door een afluisterende derde partij. Ook zou men zich een gecorrumpeerde implementatie kunnen voorstellen, onbekend voor beide partijen (dit kan eenvoudig voorkomen bij een product dat alleen als binaries wordt geleverd, zoals vaak het geval is bij commerciële producten). Dit kan simpel gebeuren, en in dit geval hoeft alleen de server of de client "geïnfecteerd te worden. Ondanks het feit dat zo'n bekende fout in het protocol is achtergelaten, (vooral daar het wijd en zijd bekend is dat de installatie van een "bedekt kanaal" in een encryptie product DE klassieke en eenvoudigste manier is om de communicatie te corrumperen) lijkt het me vrij onwaarschijnlijk dat hier veel misbruik van zou worden gemaakt. Het kan interressant zijn om Bruce Schneier's opmerkingen met betrekking tot zulke elementen in producten, onder toezicht van overheids instanties. (http://www.counterpane.com/crypto-gram-9902.html#backdoors).

Ik zal dit onderwerp afsluiten met de laatste bug die ik vond tijdens het porten van SSH naar SSF (Franse versie van SSH), in de code van de Unix versie voor 1.2.25. De consequentie was dat de random generator ... voorspelbare ... resultaten opleverde (deze situatie valt te betreuren in een cryptografisch produkt, ik zal de technische details achterwege laten, maar het is mogelijk om een communicatie te compromitteren met eenvoudige afluister praktijken). Tegen de tijd dat SSH's ontwikkel team het probleem had gecorrigeerd (slechts een regel om aan te passen) werd er vreemd genoeg geen waarschuwing rondgestuurd en werd het ook niet in de "changelog" genoemd... Als iemand niet wilde dat het bekend zou worden, had hij zich niet anders gedragen. Uiteraard is er geen relatie met de link naar het bovenstaande artikel.

Conclusie

Ik zal nog eens herhalen wat ik schreef in de introductie: SSH produceert geen wonderen, noch lost het alle beveiligings problemen op, maar maakt het wel mogelijk om efficiënt met de meest kwetsbare aspecten van de historische interactieve connectie programma's (telnet, rsh...) om te gaan.

Bibliografie, essentiële links

De volgende twee boeken gaan over SSH versie 1 en SSH versie 2:

En als je wat geld wilt investeren, is hier de plek om te beginnen...:

het bedekte kanaal exploiteren (mogelijk door de random opvulling in SSHv1)

Het is mogelijk om het bedekte (subliminale) kanaal te exploiteren, welke is ontstaan door het gebruik van de random opvulling in SSHv1 (en v2). Ik ontken alle verantwoordelijkheid voor hartaanvallen die bij de meest paranoïden kunnen voorkomen.

De SSHv1 pakketten hebben de volgende structuur:

offset

(bytes)

naam

lengte

(bytes)

beschrijving

0

grootte

4

pakket grootte, veld grootte zonder opvulling, dus:

grootte = lengte(type) + lengte(data) + lengte (CRC)

4

opvulling

p =1 tot 8

random opvulling : grootte wordt zo aangepast dat het versleutelde deel een veelvoud van 8 wordt

4+p

type

1

pakket type

5+p

data

n (variable >= 0)

 

5+p+n

controlegetal

4

CRC32

Slechts een veld is niet versleuteld: de "grootte". De lengte van het versleutelde deel is altijd een veelvoud van acht, met behulp van "opvulling" (padding). De padding wordt altijd uitgevoerd, als de lengte van de laatste drie velden reeds een veelvoud van 8 is, zal de padding 8 bytes lang zijn (5+p+n, blijft over 0 modulo 8). Neem de codeer functie C, symmetrisch, gebruikt in CBC mode, en de decodeer functie C-1. Om deze demonstratie te vereenvoudigen, zullen we alleen pakketten gebruiken met 8 byte padding. Zodra een van de pakketten aankomt, zullen we, in plaats van deze te padden met een random nummer, een waarde C(M) plaatsen, in dit geval 8 bytes groot. Dit betekend het decoderen van een bericht M met de functie C, gebruikt om het kanaal te versleutelen (het feit dat M ontcijferd wordt zonder eerst versleuteld te worden heeft geen belang vanuit een strict wiskundig oogpunt, ik zal hier niet de praktische implementatie in detail uitleggen). Vervolgens gaan we door naar het normale verwerken van het pakket, oftewel het coderen van blokken van 8 bytes.

Het resultaat zal zijn:

offset

bevat

opmerkingen

0

grootte

4 bytes, niet gecodeerd

4

8 bytes opvulling (gecodeerd)

dus C(C-1(M))

12... einde

type, data, CRC

 

Wat is het verbazingwekkende hier? Het eerste gecodeerde blok bevat C(C -1 (M)) . Dus, daar C een symmetrische encryptie functie is; C(C -1(M) = M. Dit eerste blok wordt ongecodeerd verstuurd in een gecodeerde data stroom! Dit betekend alleen dat een ieder die de verbinding afluisterd en kennis heeft van de stratagem zal weten hoe de informatie geëxploiteerd kan worden. Uiteraard kan men aannemen dat het bericht gecodeerd is (met een publieke sleutel, bijvoorbeeld, welke een geheim bevat in de gecompromitteerde code), en dus beveiligd is tegen iemand die niet geïnformeerd is.

Bijvoorbeeld, er zijn drie pakketten van dit type nodig om de triple-DES (168 bit) sessie sleutel te sniffen, waarna de flux sniffer de gehele communicatie kan ontcijferen. Als de sleutel wordt verstuurd, is het net langer nodig om van te voren de padding te ontsleutelen, die vervolgens in het pakket wordt geïnjecteerd, het is mogelijk om paddings van elke grootte te gebruiken, als men nog meer informatie wil toevoegen.

Het gebruik van dit bedekte kanaal is absoluut niet detecteerbaar! (men moet erg voorzichtig zijn bij het coderen van ieder element van het bericht, zoals eerder uitgelegd, zodat de entropy van het blok niet de strategie onthuld. Niet detecteerbaar omdat de padding random is, en zo mogelijke validatie tests elimineerd. Random padding zou nooit worden toegepast in cryptografische produkten.

Wat dit kanaal nog gevaarlijker maakt dan andere in het protocol wordt veroorzaakt door berichten als SSH_MSG_IGNORE waardoor je er gebruik van kunt gebruiken zonder kennis van de gecodeerde sleutel.

Om de 'perverse' effecten van random padding te voorkomen, zou men in het protocol deterministische padding moeten definiëren: vaak ook "zelf beschrijvende padding" genoemd. Dit houdt in dat de offset byte n, n bevat. Random padding komt voor in SSH v2, het is een keus, dus hou het in gedachten...

Ter afsluiting, zou ik nog willen zeggen dat als ik het bedekte kanaal becritiseer, het alleen is omdat ik graag wil zien dat een produkt als SSH, welke zich toelegt op sterke beveiliging, een maximum aan beveiliging levert. Nu ben je in staat om je voor te stellen dat er meer potentiële problemen liggen in commerciële produkten: alleen open source produkten kunnen een oplossing bieden voor de primaire behoefte, de mogelijkheid om de code te controleren (ook al dient het controleren van de code vaak gedaan te worden.

mirror server hosted at Truenetwork, Russian Federation.