<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<!-- this stylesheet will later on be added by lfparser automatically: -->
<style type="text/css">
<!--
pre { font-familiy:monospace,Courier }
p.code { width:80%; alignment:center; background-color:#aedbe8; border-style:none; border-width:medium; border-color:#aedbe8; padding:0.1cm ; text-align:left }
-->
</style>
<title>Beveilig je connecties met SSH</title>
</head>
<body>
<h1>Beveilig je connecties met SSH</h1>
<h4>ArticleCategory:</h4>
System Administration
<h4>AuthorImage:</h4>
<img src="../../common/images/bernard.perrot.jpg" width="100"
height="138" alt="Bernard Perrot">
<h4>TranslationInfo:[Author and translation history]</h4>
<p>original in fr <a href=
"mailto:bernard.perrot(at)univ-rennes1.fr">Bernard Perrot</a>
</p>
<p>fr to en <a href="mailto:g.passemard(at)free.fr">Guy
Passemard</a> </p>
<p>en to nl <a href="nospam:ghs(at)linuxfocus.org">
GH Snijders</a> </p>
<h4>AboutTheAuthor</h4>
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).<br>
<h4>Abstract</h4>
<p>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.</p>
<p>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. </p>
<h4>ArticleIllustration:</h4>
<img src="../../common/images/illustration273.gif" alt="ssh"
hspace="10" width="320" height="95">
<h4>ArticleBody:[The article body]</h4>
<h2>Waar wordt SSH voor gebruikt?</h2>
<p>Allereerst (en historisch), SSH (het commando <i>ssh</i>
is een veilige variant van de <i>rsh</i> en <i>rlogin</i>
commando's. SSH staat voor "<i>Secure SHell</i>" zoals <i>rsh</i>
staat voor "<i>Remote SHell</i>". Dus, zoals <i>rsh</i> je
eenvoudig toegang kan geven tot shell op een andere machine,
zonder mechanisme voor gebruikers authenticatie, levert <i>SSH</i>
dezelfde mogelijkheid maar dan met een hoog niveau van
beveiliging.</p>
<p>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 <i>SSH</i> commando is, om het <i>telnet, rsh</i> of
<i>rlogin</i> commando's te vervangen en dat alles hetzelfde werkt
met betere beveiliging.</p>
<p>Dus, als je gebruik maakte van:</p>
<p> <tt>% rlogin serveur.org</tt> (of <tt>telnet
serveur.org</tt>)</p>
<p>gebruik je nu:</p>
<p> <tt>% ssh serveur.org</tt></p>
<p>en het is nu al een stuk beter!</p>
<p>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 <i>rsh</i>
(<i>rlogin</i>, <i>telnet</i>) voornamelijk een consequentie zijn
van nalatigheid van het slachtoffer.</p>
<h2>Benodigdheden</h2>
<p>Om meer informatie te geven, volgen hier een paar van de meest
cruciale en fragiele aspecten van interactieve connecties die men
graag opgelost ziet:</p>
<ul>
<li>Ten eerste, voorkom dat wachtwoorden over het net worden
gestuurd;</li>
<li>gebruik sterke authenticatie op verbonden systemen, niet
alleen gebaseerd op de naam of IP adres, welke gespoofed kunnen
worden;</li>
<li>voer remote commando's uit in volledige beveiliging.</li>
<li>bescherm het transport van bestanden;</li>
<li>beveilig X11 sessies, welke erg kwetsbaar zijn</li>
</ul>
<p>Als reactie op deze eisen, bestaan er oplossingen die niet echt
bevredigen:</p>
<ul>
<li>De "<i>R-commando's</i>": deze commando's versturen het
password niet in platte tekst, maar gebruiken het "rhosts"
mechanisme, welke onderwerp is van vele beveiligings problemen;
</li>
<li>Het "<i>One Time Password</i>, (OTP, eenmalig wachtwoord)":
beschermt alleen de authenticatie, niet de data. Ondanks dat dit
systeem uit het oogpunt van veiligheid heel aantrekkelijk is,
heeft het eigenschappen die voor gebruikers lastig te accepteren
zijn. Het wordt voornamelijk gebruikt in omgevingen waar ergonomie
van onderschikt belang is;</li>
<li>The "<i>One Time Password</i>
<li>telnet met encryptie: deze oplossing is alleen toepasbaar
op... telnet. Buiten dat, het omvat niet het X11 protocol, vaak
een vereiste toevoeging.</li>
</ul>
<p>En er is SSH, een goede oplossing voor:</p>
<ul>
<li>het vervangen van de <i>R-commands</i>:<i>ssh</i> in plaats
van <i>rsh</i> en <i>rlogin</i>, <i>scp</i> met <i>rcp</i>,
<i>sftp</i> met <i>ftp</i>; </li>
<li>Gebruikt sterke encryptie, gebaseerd op encryptie algoritmes
voor publieke sleutels (PKI), zowel voor systemen als voor
gebruikers;</li>
<li>maakt het mogelijk om de TCP data stroom in een sessie te
"tunnelen" en in X11 sessies, dit kan geautomatiseerd worden;</li>
<li> de tunnel versleutelen, en, indien gewenst, te comprimeren.
</li>
</ul>
<h4>SSH versie 1 en SSH versie 2</h4>
<p>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. </p>
<p>Het SSH versie 1 protocol is geïntegreerd, waar SSH versie
2 het vorige protocol heeft geherdefiniëerd in drie "lagen"
(layers):</p>
<ol>
<li>SSH Transport Layer Protocol (SSH-TRANS)</li>
<li>SSH Authentication Protocol (SSH-AUTH)</li>
<li>SSH Connection Protocol (SSH-CONN)</li>
</ol>
<p>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:
<a href= "http://www.ietf.org/html.charters/secsh-charter.html"
>http://www.ietf.org/html.charters/secsh-charter.html</a></p>
<p>Zonder al teveel op details in te gaan, hier is wat je kunt vinden
in SSHv2:</p>
<ul>
<li>de transport verzorgt integriteit, encryptie, compressie
en de authenticatie van systemen</li>
<li>de authenticatie laag levert ... authenticatie (password,
host-gebaseerd, public key)</li>
<li>de connectie laag welke de tunnel beheerd (shell, SSH-agent,
port forwarding, flow control).</li>
</ul>
<p>Belangrijke technische verschillen tussen SSH versie 1
en 2 zijn: </p>
<table border="1" width="582" cellpadding="1" bgcolor="#aedbe8">
<tr valign="TOP">
<th>
<p>SSH versie 1</p>
</th>
<th>
<p>SSH versie 2</p>
</th>
</tr>
<tr>
<td>
<p>monolitisch (geïntegreerd) ontwerp</p>
</td>
<td>
<p>scheiding van de authenticatie, connectie en
transport functies in lagen</p>
</td>
</tr>
<tr>
<td>
<p>integriteit via CRC32 (niet erg veilig)</p>
</td>
<td>
<p>integriteit via HMAC (hash encryptie)</p>
</td>
</tr>
<tr>
<td>
<p>een, maar dan ook echt een kanaal per sessie</p>
</td>
<td>
<p>onbeperkt aantal kanalen per sessie</p>
</td>
</tr>
<tr>
<td>
<p>onderhandeling via symmetrische codering in het
kanaal, sessie identificatie met een unieke sleutel aan
beide kanten</p>
</td>
<td>
<p>gedetailleerde onderhandeling (symmetrische codering,
publieke sleutels, compressie, ...), en een aparte sessie
sleutel, compressie en integriteit aan beide kanten</p>
</td>
</tr>
<tr>
<td>
<p>alleen RSA voor het publieke-sleutel algorithme</p>
</td>
<td>
<p>RSA en DSA voor publieke-sleutel algorithme</p>
</td>
</tr>
<tr>
<td>
<p>sessie sleutel verstuurd door client</p>
</td>
<td>
<p>sessie sleutel overeengekomen door Diffie-Hellman
protocol</p>
</td>
</tr>
<tr>
<td>
<p>sessie sleutel geldig gedurende de sessie</p>
</td>
<td>
<p>vernieuwbare sessie sleutel</p>
</td>
</tr>
</table>
<h2>Een aantal sleutels onderhouden</h2>
<p>SSH sleutel typen, laat me ze kort definiëren:</p>
<ul>
<li>User key: een sleutelpaar samengesteld uit een publieke
en een prive sleutel (beide assymetrisch), gebruiker gedefinieerd
en permanent (opgeslagen op schijf). Deze sleutel staat de
authenticatie van de gebruiker toe, als de public key
authenticatie methode wordt gebruikt (verderop meer hierover).</li>
<li>Host key: ook een sleutelpaar dat samengesteld is uit een
publieke en een prive sleutel (beide assymetrisch), maar
gegenereerd tijdens installatie/configuratie door de beheerder van
de server, en permanent (opgeslagen op schijf). Deze sleutel staat
de authenticatie tussen systemen toe</li>
<li>Server key: weer een sleutelpaar dat is samengesteld uit een
publieke en een prive sleutel (assymetrisch), maar gegenereerd door
een daemon tijdens het starten en regelmatig vernieuwd. Deze sleutel
blijft in het geheugen staan om de de uitwisseling van de sessie
sleutel te beveiligen in SSHv1 (met SSHv2 is er geen server key,
daar de uitwisseling wordt beveiligd met het Diffie-Hellman protocol).
</li>
<li>Session key:dit is een geheime sleutel die gebruikt wordt door
het encryptie algorithme om het communicatie kanaal te versleutelen.
Als altijd in moderne cryptografische producten, is deze sleutel
random en vergankelijk. SSHv1 kent een sleutel per sessie, aan beide
kanten. SSHv2 kent 2 gegenereerde sessie sleutels, een aan iedere
kant. </li>
</ul>
<p>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. </p>
<h4>Authenticatie methodes</h4>
<p>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:</p>
<ul>
<li>
<b>"telnet-achtig":</b>
<p>Dit is de "traditionele" wachtwoord methode: als er
verbinding wordt gemaakt,wordt, na het vastellen van de identiteit,
de gebruiker uitgenodigd het wachtwoord op te geven dat
bij de desbetreffende gebruiker hoort, welke naar de server
wordt verstuurd. Het resterende probleem (dat voor een
astronomisch aantal problemen zorgt op het Internet) is dat
het wachtwoord in <i>klare tekst</i> wordt rondgestuurd over
het net, zodat het door iedereen onderschept kan worden met
een eenvoudige "<i>sniffer</i>". Hier heeft SSH hetzelfde
voorkomen (het is een eenvoudige methode voor de gebruiker
om over te stappen van telnet naar SSH, daar er niets nieuws
geleerd hoeft te worden ...), maar heeft het SSH protocol
het kanaal versleuteld en wordt het wachtwoord-in-platte tekst
hierin opgenomen.</p>
<p>Een variant die zelfs nog veiliger is, en configureerbaar
mits men de juiste spullen op de server heeft is de "<i>One
Time Password</i>" methode (S/Key bijvoorbeeld): het is zeker beter,
duidelijk veiliger, maar de ergonomische nadelen maken het
alleen geschikt voor bepaalde sites. Dit systeem werkt als
volgt: nadat de identiteit is opgegeven, wordt de gebruiker
niet om een wachtwoord gevraagd, maar stuurd de server een
"<i>challenge</i>" waar de gebruiker op dient te reageren.
De challenge is altijd anders, en dus moet het antwoord mee
veranderen. Dit heeft als gevolg dat het onderscheppen
van het antwoord niet uitmaakt, daar het niet opnieuw gebruikt
kan worden. De beperking, zoals genoemd, zit in het coderen
van het antwoord, welke uitgerekend dient te worden (door een
token, software op de client, etc.), het idee is op zich is
"intrigerend". <br></p>
</li>
<li>
<b>"rhosts-achtig"</b> (<i>host gebaseerd</i>:
<p>In dit geval gebeurd de identificatie, net als met de
R-commando's, met behulp van bestanden als /etc/rhosts of
~/rhosts, welke client sites "certificeren". SSH draagt alleen
maar bij aan betere host-identificatie, en aan het gebruik van
eigen "<i>shosts</i> bestanden. Vanuit het oogpunt van beveiliging
is dit niet voldoende, en raad ik af om dit als enige methode te
gebruiken.</p>
<li>
<b>Met publieke sleutels</b>
<p>Hier zal het authenticatie systeem gebaseerd zijn op
assymetrische encryptie (zie ook het <a href=
"../May2002/article243.shtml"> artikel over encryptie</a> voor
meer details; in het kort komt het er op neer dat SSHv1 RSA
gebruikt en SSHv2 DSA mogelijk maakt). De publieke sleutel van
de gebruiker wordt van te voren opgeslagen op de server en de
prive sleutel wordt op de client opgeslagen. Met dit
authenticatie schema reizen er geen geheimen over het Internet,
en worden nooit naar de server verstuurd. </p>
<p>Dit is een schitterend systeem, maar toch is de veiligheid
ervan beperkt (vanuit mijn oogpunt) doordat het bijna exclusief
afhankelijk isvan de serieusheid van de gebruiker (dit probleem
is niet exclusief van SSH, ik geloof dat het HET probleem
is met publieke sleutel systemen, zoals het vandaag de dag
populaire PKI): dus, om compressie van de publieke sleutel op
de client systemen te voorkomen, wordt de sleutel normaal
gesproken beschermd door een wachtwoord (vaak ook een <i>
pass phrase</i>, wachtzin genoemd om het belang van meer
dan 1 <i>woord</i> aan te geven). Als de gebruiker zijn prive
sleutel niet voorzichtig (of helemaal niet) beschermt kunnen
anderen gemakkelijk toegang krijgen tot al zijn bronnen. Dat
is waarom ik beweer dat de veiligheid afhankelijk is van hoe
serieus de gebruiker is, en zijn mate van vertrouwen, daar in
dit geval de systeembeheerder <i>geen enkele</i> manier heeft
om te achterhalen of de prive sleutel veilig is, of niet.
Op het moment biedt SSH geen revocation (herroepings)
certificaten (velen doen dit niet, zelfs PKI niet...).
Bijvoorbeeld, als de prive sleutel wordt opgeslagen zonder
passphrase op een thuis computer (er zijn geen 'slechten' thuis,
dus waarom zou je jezelf lastig vallen met een pass phrase...?)
en op een dag gaat hij ter reparatie naar een belangrijke
dealer (lach niet, dit is wat er gebeurd als electronische
signaturen algemeen gaan worden...), zal de reparateur (zijn zoon,
zijn vrienden) in staan zijn op de prive sleutels van iedere
computer die op zijn tafel verschijnt, af te halen.</p>
<p>De configuratie van het SSH authenticatie mechanisme voor de
gebruiker is lichtelijk anders wanneer men SSHv1, SSHv2 of
OpenSSH gebruikt, ook voor een MacOS<sup>tm</sup> of Windows
<sup>tm</sup> client. De basis principes en stappen om te
onthouden zijn:</p>
<ul>
<li>Hoe een "assymetrisch sleutelpaar" te genereren (het
prive/publieke RSA of DSA sleutelpaar), meestal op het
client systeem, (als er verschillende clients verbinding
maken genereren we het sleutelpaar op een van de clients
en repliceren we deze naar de andere). Sommige van de Windows
<sup>tm</sup> en MacOS <sup>tm</sup> clients kennen geen
service programma's om sleutelparen te genereren, het
genereren dient dan op een Unix machine te gebeuren, alvorens
de sleutels te repliceren. Het sleutelpaar wordt opgeslagen
in de <tt>~/.ssh</tt> user directory. </li>
<li>Het kopieëren van een publieke sleutel naar servers
die gebruikt zullen worden voor de authenticatie. Dit kan
door een regel toe te voegen, welke overeenkomt met het
gegenereerde sleutelpaar in de gebruikers ~/.ssh directory,
aan een server bestand in dezelfde directory. (De naam is
afhankelijk van de SSH versie, ofwel<tt>authorized_keys</tt>
of <tt>authorization</tt>).</li>
<li>En dat is alles... als de configuratie verder authenticatie
vereist op server niveau, zal de client gevraagd worden om een
"<i>pass phrase</i>" tijdens het maken van de verbinding.<br>
</li>
</ul>
</li>
</ul>
<p>Het kan ook handig zijn om te weten dat er tenminste nog
twee elementen bestaan met betrekking op authenticatie:</p>
<ul>
<li>
<b>ssh-agent</b>
<p>Een van de redenen waarom iemand zijn prive sleutel niet
beschermd is de irritatie van het opgeven van de sleutel
voor iedere interactieve verbinding plus het feit dat de
sleutel niet gebruikt kan worden als de verbinding wordt
opgezet door een script dat in de achtergrond loopt.
Er bestaat een remedie in de vorm van <i>SSH agent</i>. Dit is
een service programma, dat, eens geactiveerd
door jou, behulpzaam kan zijn door een drie-voudige identifier
(gebruikersnaam/hostnaam/pass phrase) op te slaan, en deze
tijdens het opzetten van de verbinding kan opgeven in jouw plaats.
Aan de kant van de client wordt eenmalig om het wachtwoord
gevraagd, en dus zou je het SSO (<i>Single Sign On</i> (eenmalige
login) kunnen noemen.</p>
<p>Nu je geïnformeerd bent, staat niets je in de weg om je
prive sleutels te beveiligen, maar als je dat niet doet, is dat
jouw verantwoording, en heb je de consequenties aan jezelf te danken.
</p>
</li>
<!-- guido -->
<li>
<b>"<i>verbose</i>" mode</b>
<p>Het gebeurt dat de connectie faalt om redenen die onbekend
zijn voor de gebruiker: voeg dan eenvoudig de "<tt>-v</tt> optie
(staat voor "<i>verbose</i>") toe aan het <i>ssh</i> commando.
Aansluitend zullen er een hoop gedetailleerde mededelingen
verschijnen op je scherm gedurende de verbinding, dit zal je
vaak voldoende informatie opleveren om de oorzaak van de fout
te achterhalen.</p>
</li>
</ul>
<h2>De encryptie algorithmes</h2>
<p>Er is een verschil tussen degene om communicatie kanalen
te versleutelen (encryptie met geheime sleutels) en die voor
authenticatie (encryptie met publieke sleutels).</p>
<p>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 <i>gepatenteerd</i> 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).</p>
<p>Voor symmetrische encryptie is er bijna teveel om uit te
kiezen... Het protocol bevat een algemeen algorithme dat aanwezig
moet zijn in alle implementaties: <i>triple-DES met 3 sleutels</i>.
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:</p>
<ul>
<li>IDEA: presteerd beter dan 3DES, maar is niet helemaal vrij
van licenties onder bepaalde omstandigheden (het was vaak het
standaard algorithme in Unix versies);</li>
<li>Blowfish: erg snel, waarschijnlijk veilig, maar het algorithme
moet zich nog bewijzen met de tijd;</li>
<li>AES: de nieuwe standaard (vervangt DES), als het aan beide
zijden beschikbaar is, gebruik dan deze, hier is het voor gemaakt.
</li>
</ul>
<p>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... </p>
<h2>Port Forwarding, tunnelen</h2>
<p>SSH staat toe om een willekeurige TCP data stroom om te leiden
(<i>forwarding</i>) 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. (<i>zie ook het volgende diagram</i></p>
<p>Voor het X11 protocol gaat dit zonder byzondere handelingen door
de gebruiker in z'n werk, met transparante afhandeling van de
<i>displays</i> (schermen) en staat continue aankondigingen toe, zelfs
als ze worden gemaakt via meerdere hops.</p>
<p>Voor andere stromen is er een commando-regel optie, voor iedere
kant:<br>
</p>
<ul>
<li>
Directe verbinding tussen client en server<br>
<p><img src="../../common/images/article273/SSH.gif" alt=
"directe verbinding" width="356" height="121"></p>
<p>(voorbeeld: <tt>user@alice% telnet bob.org)<br>
</tt></p>
</li>
<li>
Lokale poort forwarding (client) naar poort op afstand (server)
<p><img src="../../common/images/article273/SSH4.gif" alt=
"port forwarding" width="356" height="211"></p>
<p>voorbeeld:<tt>user@alice% ssh -L 1234:bob.org:143
bob.org</tt></p>
<p>dit systeem staat toegang toe vanaf "<i>alice.org</i>"
naar de imap server van "<i>bob.org</i>, <br>
verbindingen van buitenaf zullen afgewezen worden door het
lokale netwerk. Ze worden alleen beschikbaar gemaakt via het
<i>localhost</i> adres, poort 1234, vanaf de imap client
uitgevoerd op "<i>alice.org</i>".</p>
<ul>
<li>(1) de gebruiker op "<i>alice.org</i>" opent (verbindt)
de SSH tunnel</li>
<li>(2) de gebruiker op <i>"alice.org"</i> configureerd
de clients lokale imap voor toegang tot de <br>
imap server die luisterd op <i>localhost</i> poort 1234<br>
</li>
</ul>
<br>
<br>
</li>
<li>
Een verre poort (client) doorsturen naar een lokale poort
(server)<br>
<p><img src="../../common/images/article273/SSH5.gif" alt=
"SSH5.gif" width="356" height="215"></p>
<p>voorbeeld: <tt>root@alice% ssh -R 1234:bob.org:143 bob.org
</tt></p>
<p>Dit is hetzelfde als hierboven, maar de poort op de host op
afstand wordt doorgestuurd. Alleen root heeft de benodigde
privileges om dit SSH commando uit te voeren, maar iedere
gebruiker kan vervolgens gebruik maken van deze doorgestuurde
poort/tunnel.</p>
</li>
</ul>
</li>
</ul>
<p>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
("<i>root</i>"). Aan de andere kant, wanneer een geprivileergde
poort lokale poort doorgestuurd dient te worden, moet het ofwel
met een <i>root</i> account gebeuren, of de client moet voorzien
worden van super-user privileges ("<i>suid</i>") (in feite staat
een geprivileergde lokale poort een herdefinitie van een standaard
service toe).</p>
<p>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 "<a href= "http://www.linuxdoc.org/HOWTO/VPN-HOWTO.html"
>Linux VPN-HOWTO</a>" lezen voor meer details en setup scripts (er
bestaan ook 'native' VPN oplossingen voor Linux, zoals "<i>stunnel"</i>
welke je zou moeten bekijken alvorens een beslissing te nemen).</p>
<p>Onthoud dat de eerste mogelijkheid is om <i>telnet</i> stromen
om te leiden: dit lijkt volledig nutteloos, daar SSH interactieve
verbindingen standaard implementeerd. Echter, met behulp van het
doorsturen van <i>telnet</i> verbindingen, kun je je favoriete
client blijven gebruiken in plaats van de SSH interactieve modus.
Vooral in een Windows<sup>tm</sup> of MacOs<sup>tm</sup> 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 "<i>Mindterm</i> 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.</p>
<p>Op dezelfde manier, kun je ook een client op afstand starten,
zoals een "<i>xterm</i>" (met behulp van de automatische X11
forwarding in SSH), welke ons toestaat SSH te gebruiken op X
terminals.</p>
<p>Merk op dat de tunnel openblijft, zolang er data doorheen
gaat, zelfs als dit niet van de client komt. Dus, het "<i>sleep</i>"
commando wordt erg bruikbaar om een SSH te openen om een nieuwe
TCP connectie door te sturen. </p>
<p><tt> % ssh -n -f -L 2323:serveur.org:23 serveur.org sleep
60</tt></p>
<p><tt> % telnet localhost 2323</tt></p>
<p><tt> ... welkom bij serveur.org ...</tt></p>
<p>De eerste regel opent de tunnel, start het commando
"<i>sleep 60</i>" op de server, en stuurt de lokale poort
2323 naar de (<i>telnet</i>) poort nummer 23 op serveur.org. De
tweede start een <i>telnet</i> client op de lokale poort 2323
en zal dan de (versleutelde) tunnel gebruiker met de <i>telnetd</i>
daeon op de server verbinden. Het "<i>sleep</i>" 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.<p>
<h2>Belangrijkste distributies: vrij beschikbaar</h2>
<p>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.</p>
<table border="1" width="553" cellpadding="1" bgcolor="#aedbe8">
<tr>
<th>
<p>produkt</p>
</th>
<th>
<p>platform</p>
</th>
<th>
<p>protocol</p>
</th>
<th>
<p>link</p>
</th>
<th>
<p>opmerking</p>
</th>
</tr>
<tr>
<td>
<p>OpenSSH</p>
</td>
<td>
<p>Unix</p>
</td>
<td>
<p>versies 1 en 2</p>
</td>
<td>
<p><a href=
"http://www.openssh.com/">www.openssh.com</a></p>
</td>
<td>
<p>details onder</p>
</td>
</tr>
<tr>
<td>
<p>TTSSH</p>
</td>
<td>
<p>Windows<sup>tm</sup></p>
</td>
<td>
<p>versie 1</p>
</td>
<td>
<p><a href=
"http://www.zip.com.au/~roca/ttssh.html"
>www.zip.com.au/~roca/ttssh.html</a></p>
</td>
<td>
</td>
</tr>
<tr>
<td>
<p>Putty</p>
</td>
<td>
<p>Windows<sup>tm</sup></p>
</td>
<td>
<p>versie 1 en 2</p>
</td>
<td>
<p><a href=
"http://www.chiark.greenend.org.uk/~sgtatham/putty/"
>www.chiark.greenend.org.uk/~sgtatham/putty</a></p>
</td>
<td>
<p>alleen beta</p>
</td>
</tr>
<tr>
<td>
<p>Tealnet</p>
</td>
<td>
<p>Windows<sup>tm</sup></p>
</td>
<td>
<p>versie 1 en 2</p>
</td>
<td>
<p><a href=
"http://telneat.lipetsk.ru/">telneat.lipetsk.ru</a></p>
</td>
<td>
</td>
</tr>
<tr>
<td>
<p>SSH secure shell</p>
</td>
<td>
<p>Windows<sup>tm</sup></p>
</td>
<td>
<p>versies 1 en 2</p>
</td>
<td>
<p><a href="http://www.ssh.com/">www.ssh.com</a></p>
</td>
<td>
<p>vrij voor niet-commercieel gebruik</p>
</td>
</tr>
<tr>
<td>
<p>NiftytelnetSSH</p>
</td>
<td>
<p>MacOS<sup>tm</sup></p>
</td>
<td>
<p>versie 1</p>
</td>
<td>
<p><a href=
"http://www.lysator.liu.se/~jonasw/freeware/niftyssh/"
>www.lysator.liu.se/~jonasw/freeware/niftyssh/</a></p>
</td>
<td>
</td>
</tr>
<tr>
<td>
<p>MacSSH</p>
</td>
<td>
<p>MacOS<sup>tm</sup></p>
</td>
<td>
<p>versie 2</p>
</td>
<td>
<p><a href=
"http://www.macssh.com/">www.macssh.com</a></p>
</td>
<td>
</td>
</tr>
<tr>
<td>
<p>MindTerm</p>
</td>
<td>
<p>Java</p>
</td>
<td>
<p>versie 1</p>
</td>
<td>
<p><a href=
"http://www.mindbright.se/">www.mindbright.se</a></p>
</td>
<td>
<p>v2 nu commercieel</p>
</td>
</tr>
</table>
<p>Merk op dat MindTerm zowel een onafhankelijke implementatie
in Java is, (je hebt alleen een Java <i>runtime</i> nodig) als
een <i>servlet</i> 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.</p>
<h2>OpenSSH </h2>
<p>Tegenwoordig is dit waarschijnlijk de distributie om te gebruiken
in een Unix/Linux omgeving (continue ondersteuning, goede respons
tijden, open source en vrij). </p>
<p>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.</p>
<p>Dit alles heeft z'n consequenties, vooral daar de code steeds meer
en meer een monster aanpassing wordt (ik voel het "<i>sendmail</i>"
syndroom aan de horizon verschijnen, dit is niet erg gunstig voor
een applicatie is gericht op encryptie die extreem rigoreus zou
moeten zijn).</p>
<p>Behalve schoon en leesbare coden, ergeren twee andere punten me:
</p>
<ul>
<li>OpenSSH gebruikt voor z'n encryptie services de OpenSSL
library, en meestal is deze dynamisch gelinkt. In ons geval, lijkt
me deze implementatie van een encryptie utilitie pakket met
karakteristieken als een hoog beveiligings niveau en zeer betrouwbare
features, een slechte benadering. Natuurlijk, een aanval op de
library is gelijk aan een aanval op het product. Anders dan een
perverse aanval, zullen de encryptie karakteristieken (kwaliteit)
in OpenSSH dezelfde zijn/worden als die van de library, welke z'n
leven onafhankelijk van OpenSSH leeft.</li>
<li>OpenSSH gebruikt voor sommige van z'n gevoelige services
(zoals bijvoorbeeld een random-nummer generator), de OpenBSD system
services. In deze context, zal ik dezelfde opmerkingen maken over
externe afhankelijkheden als bij OpenSSL. Nog irritanter is, dat
de portable versie van OpenSSH, die op meerdere platformen zou
moeten werken, services die door OpenBSD benodigd zijn, delegeert
naar andere mechanismen op de doel platformen. Of er bijvoorbeeld
nu een random-nummer generator beschikbaar is of niet, voor jouw
systeem, we zullen het gebruiken of anders een andere interne.
Aansluitend wordt de effectiviteit van OpenSSH afhankelijk van het
onderliggende platform, oftewel, je moet maar afwachten wat het
wordt.</li>
</ul>
<p>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. </p>
<p>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.</p>
<h2>Slecht nieuws ...</h2>
<p>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.</p>
<p>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 <i>httpd</i>) en is onzichtbaar voor
een "ps" commando (ook aangepast door de rootkit).</p>
<p>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 ;-). </p>
<p>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 "<i>man in the middle</i> aanvallen te lezen:
<a href=
"http://www.hsc.fr/ressources/presentations/mitm/index.html"
> http://www.hsc.fr/ressources/presentations/mitm/index.html</a>.
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).</p>
<ul>
<li>
"Man in the middle" aanval:<br>
<p><img src="../../common/images/article273/SSH3.gif" alt=
"SSH3.gif" width="503" height="257"></p>
<p>De agressor onderschept de pakketten van beide zijden, en
genereert zijn pakketten om beiden te bedriegen<br>
(afwijkende scenarios zijn mogelijk, bijvoorbeeld met het
afsluiten van de verbinding aan de ene kant,<br>
en aan de andere kant doorgaan, terwijl deze kant ervan
overtuigd is dat het de normale partner is)</p>
</li>
</ul>
<p>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 <i>n</i> aan de byte positie (<i>zelf beschrijvend
opvullen</i>). 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.
(<a href= "http://www.counterpane.com/crypto-gram-9902.html#backdoors"
>http://www.counterpane.com/crypto-gram-9902.html#backdoors</a>).</p>
<p>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.</p>
<h4>Conclusie</h4>
<p>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.</p>
<h4>Bibliografie, essentiële links</h4>
<p>De volgende twee boeken gaan over SSH versie 1 en SSH versie 2: </p>
<ul>
<li><i>SSH: the Secure Shell</i><br>
Daniel J. Barret & Richard E. Silverman<br>
O'Reilly - ISBN 0-596-00011-1<br>
</li>
<li><i>Unix Secure Shell</i><br>
Anne Carasik<br>
McGraw-Hill - ISBN 0-07-134933-2</li>
<li><a href=
"http://www.openssh.com/">openssh: http://www.openssh.com</a></li>
</ul>
<p>En als je wat geld wilt investeren, is hier de plek om te
beginnen...:</p>
<ul>
<li><a href="http://www.ssh.com/">http://www.ssh.com</a></li>
</ul>
<h2>het bedekte kanaal exploiteren (mogelijk door de random opvulling
in SSHv1)</h2>
<p>
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.</p>
<p>De SSHv1 pakketten hebben de volgende structuur:</p>
<table border="1" width="565" cellpadding="1" bgcolor="#aedbe8">
<tr>
<td>
<p><b>offset</b></p>
<p><b>(bytes)</b></p>
</td>
<td>
<p><b>naam</b></p>
</td>
<td>
<p><b>lengte</b></p>
<p><b>(bytes)</b></p>
</td>
<td>
<p><b>beschrijving</b></p>
</td>
</tr>
<tr>
<td>
<p>0</p>
</td>
<td>
<p>grootte</p>
</td>
<td>
<p>4</p>
</td>
<td>
<p>pakket grootte, veld grootte zonder opvulling, dus:</p>
<p>grootte = lengte(type) + lengte(data) + lengte (CRC)</p>
</td>
</tr>
<tr>
<td>
<p>4</p>
</td>
<td>
<p>opvulling</p>
</td>
<td>
<p>p =1 tot 8</p>
</td>
<td>
<p><b>random</b> opvulling : grootte wordt zo aangepast
dat het versleutelde deel een veelvoud van 8 wordt</P>
</td>
</tr>
<tr>
<td>
<p>4+p</p>
</td>
<td>
<p>type</p>
</td>
<td>
<p>1</p>
</td>
<td>
<p>pakket type</p>
</td>
</tr>
<tr>
<td>
<p>5+p</p>
</td>
<td>
<p>data</p>
</td>
<td>
<p>n (variable >= 0)</p>
</td>
<td>
</td>
</tr>
<tr>
<td>
<p>5+p+n</p>
</td>
<td>
<p>controlegetal</p>
</td>
<td>
<p>4</p>
</td>
<td>
<p>CRC32</p>
</td>
</tr>
</table>
<p>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 (<i>5+p+n</i>, blijft over 0
modulo 8). Neem de codeer functie <i>C</i>, symmetrisch,
gebruikt in CBC mode, en de decodeer functie <i>C<sup>-1</sup></i>.
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 <i>C<sup-1</sup>(M)</i> plaatsen, in dit geval 8 bytes groot.
Dit betekend het decoderen van een bericht <i>M</i> met de
functie <i>C</i>, gebruikt om het kanaal te versleutelen (het feit
dat <i>M</i> 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. </p>
<p>Het resultaat zal zijn:</p>
<table border="1" width="478" cellpadding="1" bgcolor="#aedbe8">
<tr>
<td>
<p><b>offset</b></p>
</td>
<td>
<p><b>bevat</b></p>
</td>
<td>
<p><b>opmerkingen</b></p>
</td>
</tr>
<tr>
<td>
<p>0</p>
</td>
<td>
<p>grootte</p>
</td>
<td>
<p>4 bytes, niet gecodeerd</p>
</td>
</tr>
<tr>
<td>
<p>4</p>
</td>
<td>
<p>8 bytes opvulling (gecodeerd)</p>
</td>
<td>
<p>dus <i>C(C<sup>-1</sup>(M))</i></p>
</td>
</tr>
<tr>
<td>
<p>12... einde</p>
</td>
<td>
<p>type, data, CRC</p>
</td>
<td>
</td>
</tr>
</table>
<p>Wat is het verbazingwekkende hier? Het eerste gecodeerde
blok bevat <i>C(C <sup> -1 </sup>(M)) </i>.
Dus, daar <i>C</i> een symmetrische encryptie functie is;
<i>C(C <sup>-1</sup>(M)</i> = <i>M</i>. 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.</p>
<p>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.</p>
<p>Het gebruik van dit bedekte kanaal is <i>absoluut niet
detecteerbaar</i>! (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 <i>nooit</i> worden
toegepast in cryptografische produkten.</p>
<p>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 <i>zonder</i> kennis
van de gecodeerde sleutel.</p>
<p>Om de 'perverse' effecten van random padding te voorkomen,
zou men in het protocol deterministische padding moeten
definiëren: vaak ook "<i>zelf beschrijvende padding</i>"
genoemd. Dit houdt in dat de offset byte <i>n</i>, <i>n</i> bevat.
Random padding komt voor in SSH v2, het is een keus, dus hou het
in gedachten... </p>
<p>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.</p>
</body>
</html>