Archief - Opdracht internet: HTTP & Tunneling
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
ShPonGle
Legacy Member
heb ier een zelf geschreven tekstje, hoop dat alles beetje klopt want leer nog elke dag erover bij 
edit: tis wel niet zozeer voor HTTP, tis eig puur VPN via PPTP
moja zal et laten staan
1. Dynamic DNS
Om uw pc of modemrouter altijd bereikbaar te maken dien je hem een vaste naam toe te kennen, omdat internet ip's veranderlijk zijn. Bepaalde websites bieden een gratis dnsdienst aan die werkt met een of ander programma dat op een pc moet geïnstalleerd worden en waar de aangemaakte account moet toegevoegd worden. Over deze tools zal ik hier niet verder uitweiden, ik wil enkel meegeven dat de meeste tegenwoordige modemrouters deze dnsdienst ook zelfstandig kunnen verzorgen zonder dat er een tooltje moet installeerd worden op één van de pc's. Het enige wat je dan nog dient te doen is de dienst op de router activeren, de logingegevens en paswoord van de gekozen formule invoeren en de nodige portforwarding te leggen indien je meerdere pc's wil bereiken.
2. RAS en VPN op Windows XP
RAS gaat in essentie over 2 zaken. Ten eerste het koppelen van twee aparte netwerken in één zo veilig mogelijke tunnelverbinding, en ten tweede het aansturen van de authenticatie in deze netwerken ten opzichte van elkaar: welke gebruikers mogen wat?
Zoals je merkt dient er bij het aanmaken van een werkende VPN-serververbinding dus zowel een fysiek en logisch toegangspad (routing) als een geldig authorisatiepad voor aanmelding vanop afstand (remote access) aangelegd te worden. Ik zal hier bondig even toelichten wat deze zeer concreet inhouden voor configuratie van een VPN-server via PPTP op windows XP Professional. Ik veronderstel in mijn tutorial dat de modemrouter altijd bereikbaar is vanaf het internet via een dnsdienst zoals No-Ip of DynDNS.
Routing:
1. Forward eerst op de router de tcp-poort 1723 (is nodig voor PPTP) naar de gewenste VPN-server. Daarnaast is het belangrijk dat vooraf de specifieke firewall van de juiste netwerkverbinding geconfigureerd wordt. Je gaat naar de windows firewall, tabblad geavanceerd, kiest daar de instellingen van de hoofdnetwerkverbinding met internettoegang, en zet daar een vinkje om PPTP toe te staan vanaf internet, op het tweede tabblad ICMP kun je eventueel de mogelijkheid om te pingen ook aanzetten.
2. Voeg indien gewenst de route naar de netwerkrange persistent toe met het subnetmask en de gebruikte gateway:
Bijvoorbeeld:
Route –p add 192.168.76.0 mask 255.255.255.0 192.168.246.253
waarbij
192.168.76.0 slaat hier op het doelsubnet, host-id is hier nul omdat we alle hosts in de range willen bereiken.
192.168.246.253 doelt hier op de huidige gateway: dit is een router, een ISA-server, ....van waar ik verbinding wil maken naar het externe netwerk.
Remote Access:
1) Installatie van een RAS-server op Windows XP:
Het enige wat je hier feitelijk moet doen is de Routing and Remote Access service op automatisch zetten en starten. Bij netwerkverbindingen onder het configuratiescherm verschijnt een nieuw icoon, Binnenkomende verbindingen.
2) Authenticatie:
Stel de gemachtigde gebruikers en hun bevoegdheden in door de eigenschappen te kiezen van dit icoon binnenkomende verbindingen, tabblad Gebruikers. Vergeet bij tabblad Algemeen niet aan te vinken dat er ‘gevpnd’ mag worden. Stel in het tabblad Netwerk bij TCP/IP-eigenschappen de uit te delen ips voor de rasclients in (het eerste ip wordt altijd dat van de rasserver, het tweede is voor de eerste client, enz....) en hoe deze uitgedeeld mogen worden (vast gereserveerde range of via, dwz ge krijgt wat er vrij is). Zorg ook dat 'allow network access' ingeschakeld is indien je dit wenst (logisch).
Nu de serverzijde volledig opgezet is, kunnen wij ons oriënteren naar de client. Hier is het veel eenvoudiger. Poorten openzetten hoeft namelijk niet, want het gaat om een uitgaande verbinding vanuit de client, dus die wordt normaal gezien niet geblokkeerd door een of andere firewall. Enkel het Wizardje van Oz volgen, en de juiste dingen invullen. Nu moet dat het gewoonweg doen, of je gaat beter bij de spoorwegen werken.
Tips:
*HTTP, FTP, RDP en andere sessies kun je zowel op de interne netbiosnaam te doen als op het RASSERVER –ip. Let wel altijd op dnsnaamresolutie (doe een ping –a), doe desnoods een ipconfig /flushdns, bewerk indien gewenst de hostsfile, de lmhosts.sam file of typ steeds zelf het rasserver-ip in.
*Wanneer je aangelogd zit via VPN op de rasserver, verbreek dan de verbinding niet op de server zelf, anders zal de RAS-service in de knoop raken. Verbreek de verbinding liever vanaf de client, dan kun je er ook meteen weer op.
*Wanneer je tijdens een VPN-sessie op de client problemen hebt om te internetten, dan moet je het vinkje uitzetten bij 'use default gateway on remote network' in de geavanceerde eigenschappen van de TCP-IP instellingen van de VPN-verbinding.
Twee zeer eenvoudige tutorials die ongeveer hetzelfde vertellen staan hier:
http://gathering.tweakers.net/forum/list_messages/856814
http://gathering.tweakers.net/forum/list_messages/860645
3. Gebruik van trigger ports op modemrouter
Als ik nog één tip mag aanraden i.v.m. het gebruik van DynDNS en hierop gebaseerde RDP, HTTP, FTP, VPN, ... enz., dan is dat wel het gebruik van triggerpoorten op uw router. Concreet houdt dit in dat u voor elk van deze zaken op uw router zelf een poort instelt die als portier dient om vervolgens de juiste poort te openen voor gebruik van het gewenste protocol. Wanneer u zelf dus dan een verbinding wilt leggen, dient u achter uw dyndns-adres de gewenste poort te specificeren.
Op beveiligingsgebied biedt dit vanzelfsprekend een enorm voordeel: wie de triggerpoort niet kent, komt gewoon niet binnen, ook al weet die het ip of de domeinnaam en de gebruikte protocollen. Iedereen kan anders namelijk proberen binnen te breken d.m.v. uw dynamische domeinnaam te gebruiken. U kan dus anderzijds ook de standaardpoorten voor RDP, FTP, HTTP, ... wijzigen, een combinatie van beide voornoemde zaken is natuurlijk nog veiliger, maar vergt wel wat meer opzoekwerk en configuratie.
Om u toch een beetje op weg te helpen:
In windows kunt u de gebruikte standaardpoorten raadplegen door de volgende file te openen met notepad:
%systemroot%/system32/drivers/etc/services
edit: tis wel niet zozeer voor HTTP, tis eig puur VPN via PPTP
moja zal et laten staan 1. Dynamic DNS
Om uw pc of modemrouter altijd bereikbaar te maken dien je hem een vaste naam toe te kennen, omdat internet ip's veranderlijk zijn. Bepaalde websites bieden een gratis dnsdienst aan die werkt met een of ander programma dat op een pc moet geïnstalleerd worden en waar de aangemaakte account moet toegevoegd worden. Over deze tools zal ik hier niet verder uitweiden, ik wil enkel meegeven dat de meeste tegenwoordige modemrouters deze dnsdienst ook zelfstandig kunnen verzorgen zonder dat er een tooltje moet installeerd worden op één van de pc's. Het enige wat je dan nog dient te doen is de dienst op de router activeren, de logingegevens en paswoord van de gekozen formule invoeren en de nodige portforwarding te leggen indien je meerdere pc's wil bereiken.
2. RAS en VPN op Windows XP
RAS gaat in essentie over 2 zaken. Ten eerste het koppelen van twee aparte netwerken in één zo veilig mogelijke tunnelverbinding, en ten tweede het aansturen van de authenticatie in deze netwerken ten opzichte van elkaar: welke gebruikers mogen wat?
Zoals je merkt dient er bij het aanmaken van een werkende VPN-serververbinding dus zowel een fysiek en logisch toegangspad (routing) als een geldig authorisatiepad voor aanmelding vanop afstand (remote access) aangelegd te worden. Ik zal hier bondig even toelichten wat deze zeer concreet inhouden voor configuratie van een VPN-server via PPTP op windows XP Professional. Ik veronderstel in mijn tutorial dat de modemrouter altijd bereikbaar is vanaf het internet via een dnsdienst zoals No-Ip of DynDNS.
Routing:
1. Forward eerst op de router de tcp-poort 1723 (is nodig voor PPTP) naar de gewenste VPN-server. Daarnaast is het belangrijk dat vooraf de specifieke firewall van de juiste netwerkverbinding geconfigureerd wordt. Je gaat naar de windows firewall, tabblad geavanceerd, kiest daar de instellingen van de hoofdnetwerkverbinding met internettoegang, en zet daar een vinkje om PPTP toe te staan vanaf internet, op het tweede tabblad ICMP kun je eventueel de mogelijkheid om te pingen ook aanzetten.
2. Voeg indien gewenst de route naar de netwerkrange persistent toe met het subnetmask en de gebruikte gateway:
Bijvoorbeeld:
Route –p add 192.168.76.0 mask 255.255.255.0 192.168.246.253
waarbij
192.168.76.0 slaat hier op het doelsubnet, host-id is hier nul omdat we alle hosts in de range willen bereiken.
192.168.246.253 doelt hier op de huidige gateway: dit is een router, een ISA-server, ....van waar ik verbinding wil maken naar het externe netwerk.
Remote Access:
1) Installatie van een RAS-server op Windows XP:
Het enige wat je hier feitelijk moet doen is de Routing and Remote Access service op automatisch zetten en starten. Bij netwerkverbindingen onder het configuratiescherm verschijnt een nieuw icoon, Binnenkomende verbindingen.
2) Authenticatie:
Stel de gemachtigde gebruikers en hun bevoegdheden in door de eigenschappen te kiezen van dit icoon binnenkomende verbindingen, tabblad Gebruikers. Vergeet bij tabblad Algemeen niet aan te vinken dat er ‘gevpnd’ mag worden. Stel in het tabblad Netwerk bij TCP/IP-eigenschappen de uit te delen ips voor de rasclients in (het eerste ip wordt altijd dat van de rasserver, het tweede is voor de eerste client, enz....) en hoe deze uitgedeeld mogen worden (vast gereserveerde range of via, dwz ge krijgt wat er vrij is). Zorg ook dat 'allow network access' ingeschakeld is indien je dit wenst (logisch).
Nu de serverzijde volledig opgezet is, kunnen wij ons oriënteren naar de client. Hier is het veel eenvoudiger. Poorten openzetten hoeft namelijk niet, want het gaat om een uitgaande verbinding vanuit de client, dus die wordt normaal gezien niet geblokkeerd door een of andere firewall. Enkel het Wizardje van Oz volgen, en de juiste dingen invullen. Nu moet dat het gewoonweg doen, of je gaat beter bij de spoorwegen werken.
Tips:
*HTTP, FTP, RDP en andere sessies kun je zowel op de interne netbiosnaam te doen als op het RASSERVER –ip. Let wel altijd op dnsnaamresolutie (doe een ping –a), doe desnoods een ipconfig /flushdns, bewerk indien gewenst de hostsfile, de lmhosts.sam file of typ steeds zelf het rasserver-ip in.
*Wanneer je aangelogd zit via VPN op de rasserver, verbreek dan de verbinding niet op de server zelf, anders zal de RAS-service in de knoop raken. Verbreek de verbinding liever vanaf de client, dan kun je er ook meteen weer op.
*Wanneer je tijdens een VPN-sessie op de client problemen hebt om te internetten, dan moet je het vinkje uitzetten bij 'use default gateway on remote network' in de geavanceerde eigenschappen van de TCP-IP instellingen van de VPN-verbinding.
Twee zeer eenvoudige tutorials die ongeveer hetzelfde vertellen staan hier:
http://gathering.tweakers.net/forum/list_messages/856814
http://gathering.tweakers.net/forum/list_messages/860645
3. Gebruik van trigger ports op modemrouter
Als ik nog één tip mag aanraden i.v.m. het gebruik van DynDNS en hierop gebaseerde RDP, HTTP, FTP, VPN, ... enz., dan is dat wel het gebruik van triggerpoorten op uw router. Concreet houdt dit in dat u voor elk van deze zaken op uw router zelf een poort instelt die als portier dient om vervolgens de juiste poort te openen voor gebruik van het gewenste protocol. Wanneer u zelf dus dan een verbinding wilt leggen, dient u achter uw dyndns-adres de gewenste poort te specificeren.
Op beveiligingsgebied biedt dit vanzelfsprekend een enorm voordeel: wie de triggerpoort niet kent, komt gewoon niet binnen, ook al weet die het ip of de domeinnaam en de gebruikte protocollen. Iedereen kan anders namelijk proberen binnen te breken d.m.v. uw dynamische domeinnaam te gebruiken. U kan dus anderzijds ook de standaardpoorten voor RDP, FTP, HTTP, ... wijzigen, een combinatie van beide voornoemde zaken is natuurlijk nog veiliger, maar vergt wel wat meer opzoekwerk en configuratie.
Om u toch een beetje op weg te helpen:
In windows kunt u de gebruikte standaardpoorten raadplegen door de volgende file te openen met notepad:
%systemroot%/system32/drivers/etc/services
zukketwuk
Legacy Member
Ik heb ooit ook nog eens zo'n opdracht moeten maken, dit is de tekst die wij gebruikt hebben:
Houd je klaar voor een hele lange post
:
Deel1:
HyperText Transfer Protocol (HTTP)
1. Inleiding
Het idee achter het HTTP-protocol waarmee clients en servers met elkaar praten, is ontwikkeld door mensen van het CERN (Europees Centrum voor Nuclair Onderzoek) in Geneve.
Toen zij hun onderzoek over het delen van documenten tussen computers hadden afgerond, gaven ze het project over aan een Amerikaanse Universiteit (NSCA).
2. Wat is HTTP?
HTTP (Hypertext Transfer Protocol) is een TCP/IP-applicatielaagprotocol en omvat regels of protocollen die zorgen dat webpagina’s via verschillende computers geraadpleegd kunnen worden. Dit gebeurt wanneer je een adres in de browser invoert of je op een link klikt. Het protocol is verdeeld in twee delen: de vraag van de client en het antwoord van de server.
3. Begrippen
Cliënt/server
De cliënt is het programma waarmee aan de server wordt bericht dat er een bepaald proces moet worden uitgevoerd, bijvoorbeeld het laten zien van een website.
De server is het programma dat het proces uitvoert. Op internet zoeken de gebruikers meestal met een cliënt op het eigen systeem, zoals de browser, naar een server die ergens op internet actief is.
Communicatie tussen beiden gebeurt via TCP/IP, wat het vorig trimester uitgebreid aan bod kwam.
Directory
Een website heeft op een computer of webserver altijd een eigen directory. In deze directory komen alle bestanden te staan die via internet opvraagbaar moeten zijn. Dat zijn dus de webpagina's (HTML bestanden), afbeeldingen die op de webpagina’s staan enz.
Verschillende benamingen kunnen onder andere “home directory”, “website directory”, “root”, “web root”, ... zijn.
HTTP-versies
We onderscheiden 2 versies HTTP: HTTP1.0 en het recentere (en betere) HTTP1.1
Er zijn 3 belangrijke verschillen:
- Er wordt één verbinding opengehouden om alles door te sturen, waar bij versie 1.0 voor alles afzonderlijk (afbeeldingen, tekst,...) een apparte verbinding wordt gemaakt met de server.
- Tekst kan gecomprimeerd worden, wat de snelheid bevordert.
- ...
4. Het tot stand brengen van een verbinding
Tenzij de gebruiker of de hyperlink het IP-adres van de server specifieert, is de eerste stap in het tot stand brengen van een verbinding tussen twee systemen het achterhalen van het adres door een name resolution-verzoek naar een DNS-server te versturen.
Met dit adres kan het IP-protocol verkeer naar de server dirigeren.
Als de cliënt dit adres eenmaal weet, zal deze een TCP-verbinding met poort 80 van de server maken.
Nu is de TCP-verbinding tot stand gekomen en kunnen browser en server HTTP-berichten uitwisselen. Deze berichten bestaan uit 2 berichttypes: HTTP-verzoeken en HTTP-aanvragen. Deze twee berichttypes kan je dan nog eens opsplitsen in de volgende elementen:
- start line: Bevat een verzoekopdracht of reply status indicator, en enkele variabelen.
- headers: Bevatten een serie velden met informatie over het bericht of het systeem waar het afkomstig van is.
- empty line: Een witregel die het einde van de header aangeeft.
- message body: bevat de inhoud die naar het andere systeem verzonden wordt.
5. HTTP-verzoeken
De beginregel van een HTTP-verzoek ziet er als volgt uit:
Request Type - Request URI - HTTP Versie
5.1 Request Type
Er zijn acht types van verzoekberichten of request types:
get; head; post; options; put; delete; trace; connect
We bespreken even de 2 belangrijkste:
GET: Het grootste deel van de HTTP-verzoeken bestaat uit dit type verzoek.
Dit bevat een verzoek naar informatie die in de request URI(zie verder) is gespecifieerd.
POST: Vraagt aan dat de informatie in de message body door het doelsysteem geaccepteerd wordt als ondergeschikt aan de bron die in de request URI is beschreven.
Request URI
Request URI is een variabele en bevat een Uniform Resource Identifier. Dit is een tekenreeks die specifiek verwijst naar een unieke bron op het doelsysteem. Deze variabele kan bijvoorbeeld de naam bevatten van een bestand op de webserver dat de cliënt van deze server wenst te ontvangen, of de naam van de directory waaruit de server dit bestand moet versturen. De variabele HTTPversion gaat na welke HTTP-versie door het systeem
ondersteund wordt.
Dus als je nu als gebruiker de naam van een website invoert in je browser, zal het verzoekbericht er als volgt uitzien:
GET / HTTP/1.1
De opdracht GET verzoekt de server een bestand te sturen. De “/” verwijst naar de directory van de website, zodat de webserver kan antwoorden door het standaardbestand uit zijn homedirectory door te sturen.
6. HTTP-antwoorden
De basiselementen van HTTP-antwoorden, gegenereerd door de webserver, bevatten veel dezelfde elementen als van de verzoeken. De beginregel bestaat uit:
HTTPVersion StatusCode StatusPhrase
HTTP Version: Verwijst naar de standaard die door de server wordt ondersteund.
Status Code/Status Phrase: Gaat na of de server het verzoek succesvol verwerkt heeft, met de nodige uitleg erbij. De code is een getal van 3 cijfers en de Status Phrase bestaat uit strings.
De codewaardes zijn gedefinieerd in de HTTP-specificatie en worden door alle webserveruitvoeringen eenduidig gebruikt. Het eerste cijfer van de code specifieert de algemene aard van het antwoord en de andere twee geven wat meer uitleg over de code.
Ook al wordt de status phrase eveneens gedefinieerd in de specificatie, bij sommige webserverproducten kan je de tekststring aanpassen om meer informatie aan de cliënt te verstrekken. We geven een overzicht van de codes en phrases:
6.1 Informational Codes (1xx)
Dit type bevat maar 1 code en wordt gebruikt in antwoorden zonder message body.
100-Continue
6.2 Successful Codes (2xx)
Geven aan dat het verzoek van de cliënt ontvangen, begrepen en geaccepteerd is.
200-OK; 201-Created; 202-Accepted; 203-Nonauthoritative Information;
204-No Content; 205-Reset Content; 206-Partial Content
6.3 Redirection Codes (3xx)
Geeft aan dat om een verzoek te kunnen verwerken, er een volgende handeling van de client nodig is.
300-Multiple Choices; 301-Moved Permanently; 302-Found; 303-See Other;
304-Not Modified; 305-Use Proxy; 306-Unused; 307-Temporary Redirect
6.4 Client Error Codes (4xx)
Door een fout van de client kan het verzoek niet worden verwerkt.
400-Bad Request; 401-Unauthorized; 402-Payment Required; 403-Forbidden;
404-Not Found; 405-Method Not Allowed; 406-Not Acceptable;
407-Proxy Authentication Required; 408-Request Timeout; 409-Conflict; 410-Gone;
411-Length Required; 412-Precondition Failed; 413-Required Entity Too Large;
414-Required URI Too Long; 415-Unsupported Media Type;
416-Requested Range Not Satisfiable; 417-Expectation Failed
6.5 Server Error Codes (5xx)
Een verzoek kon niet verwerkt worden door een fout bij de server.
500-Internal Server Error; 501-Not Implemented; 502-Bad Gateway;
503-Service Unavailable; 504-Gateway Timeout; 505-HTTP Version Noy Supported
7. HTTP-headers
Na de beginregel of start line kan elk HTTP-bericht eventueel een serie headers bevatten. Deze bestaan uit strings en worden op deze manier ingedeeld:
Fieldname: Fieldvalue
Fieldname: Deze variabele geeft het type informatie aan dat in de header opgenomen is.
Fieldvalue: Deze bevat de informatie zelf.
De verschillende headers leveren informatie over het systeem en het verzoek waar het bericht vandaan komt. Daar kan de server gebruik van maken als deze een antwoord samenstelt. De cliënt bepaalt zelf de keuze, het aantal en volgorde van de headers, maar de HTTP-specificatie raadt aan dat dit op basis van 4 categorieën wordt geordend.
We bespreken even de 4 mogelijke waarden voor de variabele Fieldname.
Uitleg bij de waarden vind je terug in de bijlagen.
7.1 Algemene headervelden
Deze headervelden zijn toepasbaar zowel voor de aanvragen als voor de verzoeken, maar niet voor het bestand of andere informatie in de body van het bericht (entity).
De waarden voor de algemene header Fieldname zijn:
Cache-Control; Connection; Date; Pragma; Trailer; Transfer-Encoding; Upgrade; Via, Warning
7.2 Request headervelden
Deze zijn alleen van toepassing op verzoekberichten en bevatten informatie over het verzoek en systeem waarvan dit afkomstig is. Waarden zijn:
Accept; Accept-Charset; Accept-Encoding; Accept-Language; Authorization; Expect; From; Host; If-Match; If-Modified-Since; If-None-match; If-Range; If-Unmodified-Since; Max-Forwards; Proxy-Authorization; Range; Refer; TE; User Agent
7.3 Response headervelden
Deze headers zijn alleen van toepassing op antwoordberichten en bevatten informatie over meldingen en de server die deze heeft gegenereed. De response header Fieldname kan volgende waarden bevatten:
Accept-Ranges; Age; Etag; Location; proxy-Authenticate; Retry-After; Server; Vary; WWW-Authenticate
7.4 Entity headervelden
Entity beschrijft gegevens van de message body van een antwoorden geeft aanvullende informatie over deze gegevens. Waarden kunnen zijn:
Allow; Content-Encoding; Content-Language; Content-Length; Content-Location; Content-MD5; Content-Range; Content-Type; Expires; Last-Modified; Extension-Header
8. Tot slot
De headersectie wordt door een witregel afgesloten en daarna volgt de body van het bericht. Dit bevat de inhoud van het bestand waar de client om gevraagd heeft. Als het bestand groter is dan de maximale inhoud van het pakket, dan genereert de server aanvullende antwoordberichten zonder headers, alleen message bodies.
Request Types
Get: Bevat een verzoek om informatie die in de Request URI gespecifieerd is. Het grootste deel van de verzoekberichten betreft dit type verzoeken.
Head: Functioneel identiek aan het Get-verzoek, behalve dat het antwoord alleen een start line en headers bevat, geen message body.
Post: Vraagt aan dat de informatie in de message body door het doelsysteem geaccepteerd wordt als ondergeschikt aan de bron die in de Request URI is opgegeven.
Options: Bevat een verzoek naar informatie over de opties voor communicatie die beschikbaar zijn in de verzoek/antwoordketen die in de variabele RequestURI is opgegeven.
Put: Vraagt aan dat de informatie die in de message body is bijgesloten wordt opgeslagen door het doelsysteem op de locatie die in de Request URI is gespecifieerd.
Delete: Vraagt aan dat het doelsysteem de bron verwijdert die wordt opgegeven in de variabele Request URI.
Trace: Vraagt aan dat het doelsysteem een applicatielaagloopback uitvoert op het inkomende bericht en dit terugzendt naar de afzender.
Connect: Gereserveerd voor het gebruik met proxyservers die SSL-tunneling leveren.
Algemene headervelden
Cache-Control: bevat aanwijzingen die opgevolgd moeten worden door cachingmechanismen op het doelsysteem.
Connection: Specifieert de opties die voor de huidige verbinding gewenst zijn, zodat het in stand wordt gehouden voor gebruik met meerdere aanvragen.
Date: Specifieert de datum en de tijd waarop het bericht gegenereerd is.
Pragma: Specifieert aanwijzingen die uitdrukkelijk voor de client –of serveruitvoering zijn.
Trailer: Geeft aan dat specifieke headervelden aanwezig zijn aan het einde van een bericht met gecomprimeerde transfercodering.
Transfer-Encoding: Specificeert welk type transformatie is toegepast (als dit het geval is) op de message body om deze veilig naar de bestemming te verzenden.
Upgrade: Specificeert aanvullende communicatieprotocollen die door de client ondersteund worden.
Via: Geeft de gateway- en de proxyservers tussen de client en de server aan en de protocollen die ze gebruiken.
Warning: Bevat aanvullende informatie over de status of transformatie van een bericht.
Request headervelden
Accept: Specificeert de mediatypen die in het antwoordbericht geaccepteerd worden.
Accept-Charset: Specificeert de inhoudscodering die in het antwoordbericht geaccepteerd worden.
Accept-Encoding: Specificeert de inhoudscodering die in het antwoordbericht geaccepteerd worden.
Accept-Language: Specificeert de talen die in het antwoordbericht geaccepteerd worden.
Authorization: Bevat gegevens waarmee op de server de authenticiteit van de client vastgesteld zal worden.
Expect: Specificeert het gedrag dat de client van de server verwacht.
From: Bevat een e-mailadres van de gebruiker die het verzoek genereerde.
Host: Specificeert de hostnaam op internet van de bron waarom verzocht is (meestal een URL), plus een poortnummer als er een andere dan de standaardpoort 80 gebruikt wordt.
If-Match: Wordt gebruikt om een specifiek verzoek voorwaardelijk te maken door specifieke entity-tags te vergelijken.
If-Modified-Since: Wordt gebruikt om een specifiek verzoek voorwaardelijk te maken door de verwijzingsdatum van de ingang in de cache van de client waar de bron zich bevindt te specificeren, welke de server vergelijkt met de feitelijke bron en beantwoordt met ofwel de bron ofwel de cacheverwijzing.
If-None-Match: Wordt gebruikt om een specifiek verzoek voorwaardelijk te maken door specifieke entity-tags niet te vergelijken.
If-Range: Verzoekt de server delen van een entity te verzenden die de client mist.
If-Unmodified-Since: Wordt gebruikt om een specifiek verzoek conditioneel te maken door een datum op te geven die de server moet gebruiken om te bepalen of de verzochte bron geleverd moet worden.
Max-Forwards: Stelt een limiet aan het aantal proxies of gateways dat een verzoek naar een andere server kunnen doorsturen.
Proxy-Authorization: Bevat gegevens waarmee de client zijn authenticiteit bij een proxyserver bewijst.
Range: Bevat één of meerdere bytereeksen die delen van de bron voorstellen die in de Resource URI gespecificeerd zijn en waarvan de client de server vraagt deze te verzenden.
Refer: Specificeert de bron waarvan de waarde Resource URI verkregen is.
TE: Specificeert welke extension transfercoderingen de client kan accepteren in het antwoord en of de client trailer fields met gecomprimeerde transfercodering zal accepteren.
User-Agent: Bevat informatie over de browser die het verzoek heeft ingediend.
Response headervelden
Accept-Ranges: Maakt het de server mogelijk om aan te geven of het range-aanvragen van een bron accepteert (alleen in antwoorden).
Age: Specificeert de verstreken tijd sinds een gecached antwoord door een server is gegenereerd.
Etag: Specificeert de huidige waarde van de entity-tag van de gevraagde variant.
Location: Stuurt het doelsysteem naar een andere locatie van de gevraagde bron dan de in de variabele Request URI genoemde locatie.
Proxy-Authenticate: Specificeert het authenticatiesysteem dat door een proxyserver gebruikt wordt.
Retry-After: Specificeert hoe lang een gevraagde bron onbeschikbaar voor de client zal blijven.
Server: Identificeert de webserversoftware die het verzoek verwerkt heeft.
Vary: Specificeert de headervelden die gebruikt zijn om te bepalen of een client een gecached antwoord zonder revalorisatie van de server kan gebruiken als reactie op een verzoek.
WWW-authenticate: Specificeert het type authenticatie dat vereist is voor de client om toegang tot de gevraagde bron te krijgen.
Entity headervelden
Allow: Specificeert het verzoektype dat door een bron ondersteund wordt die door een specifieke waarde van de Request URI wordt aangewezen.
Content-Encoding: Specificeert aanvullende inhoud-coderingsmechanismen die op de gegevens in de body van een bericht zijn toegepast.
Content-Language: Specificeert de taal van de message body.
Content-Length: Specificeert de lengte van de message body, in bytes.
Content-Location: Specificeert de locatie waar de informatie in de message body van ontleend is, als deze niet gelijk is aan de locatie die in de Resource URI is opgegeven.
Content-MD5: Bevat een MD5-samenvatting van de message body (zoals in RFC-1864 gedefinieerd is) die op de bestemming gebruikt zal worden om de integriteit te verifiëren.
Content-Range: Identificeert de locatie van de gegevens in de message body binnen het geheel van de gevraagde bron, als het bericht alleen een deel van de bron bevat.
Content-Type: Specificeert het mediatype van de gegevens in de message body.
Expires: Specificeert de datum en de tijd waarna het antwoord in de cache als verouderd wordt beschouwd.
Last-Modified: Specificeert de datum en de tijd waarop de gevraagde bron volgens de server voor het laatst is aangepast.
Extension-Header: Maakt het gebruik van aanvullende headervelden mogelijk die zowel door de client als de server moeten worden erkend.
Informational codes
100-Continue: Geeft aan dat het verzoek door de server ontvangen is en dat de client of een ander bericht moet sturen om het verzoek te completeren of op een antwoord moet blijven wachten. Een antwoord met deze code moet gevolgd worden door een ander antwoord met daarin een code waarin de voltooiing van het verzoek wordt aangegeven.
Successful codes
200-OK: Geeft aan dat het verzoek met succes verwerkt is en dat het antwoord de juiste gegevens bevat voor het type verzoek.
201-Created: Geeft aan dat het verzoek met succes verwerkt is en dat een nieuwe bron is gemaakt.
202-Accepted: Geeft aan dat het verzoek voor verwerking geaccepteerd is, maar dat nog niet met de verwerking is begonnen.
203-Nonauthoritative Information: Geeft aan dat de informatie in de headers niet de definitieve informatie is die door de server verstrekt zal worden, maar dat deze van een lokale kopie of van een kopie van derden verzameld zal worden.
204-No Content: Geeft aan dat het verzoek met succes verwerkt is, maar dat het antwoord geen message body bevat. Het kan wel headerinformatie bevatten.
205-Reset Content: Geeft aan dat het verzoek met succes verwerkt is, en dat de clientbrowser de documentweergave moet vernieuwen. Dit bericht betekent meestal dat de gegevens uit een formulier ontvangen zijn en dat de browser de weergave moet vernieuwen door de formuliervelden leeg te maken.
206-Partial Content: Geeft aan dat het verzoek met succes verwerkt is en dat de server een verzoek beantwoord heeft dat de Range header gebruikt om delen van een bron te specificeren.
Redirection codes
300-Multiple Choices: Geeft aan dat het antwoord een lijst met bronnen bevat die gebruikt kunnen worden om aan het verzoek te voldoen en waar de gebruiker er een van moet kiezen.
301-Moved Permanently: Geeft aan dat een nieuwe URI aan de gevraagde bron is toegewezen en dat alle toekomstige referenties aan deze bron een van de nieuwe URI’s moet gebruiken die in het antwoord zijn opgenomen.
302-Found: Geeft aan dat de gevraagde bron tijdelijk onder een andere URI te vinden is, maar dat de client dezelfde waarde voor Request URI moet blijven gebruiken bij toekomstige aanvragen omdat de locatie opnieuw kan veranderen.
303-See Other: Geeft aan dat het antwoord op het verzoek onder een andere URI kan worden gevonden en dat de client een nieuw verzoek aan deze URI moet richten.
304-Not Modified: Geeft aan dat de versie van de opgevraagde bron in de cache van de clien identiek is aan die op de server en dat het opnieuw verzenden van de bron niet nodig is.
305-Use Proxy: Geeft aan dat de opgevraagde bron via de proxy die in de Location header wordt genoemd moet worden benaderd.
306-Unused
307-Temporary Redirect: Geeft aan dat de gevraagde bron tijdelijk onder een andere URI te vinden is, maar dat de client dezelfde waarde voor Request URI moet blijven gebruiken bij toekomstige aanvragen omdat de locatie opnieuw kan veranderen.
Client error codes
400-Bad Request: Geeft aan dat de server het verzoek niet begrepen heeft ten gevolge van een foutieve syntaxis.
401-Unauthorized: Geeft aan dat de server een verzoek niet kon verwerken omdat gebruikersauthenticatie vereist is.
402-Payment Requiered: Gereserveerd voor toekomstig gebruik.
403-Forbidden: Geeft aan dat de server weigert het verzoek te verwerken en dat dit niet herhaald moet worden.
404-Not Found: Geeft aan dat de server de bron die door de variabele Request URI wordt gespecificeerd niet heeft kunnen vinden.
405-Method Not Allowed: Geeft aan dat het type verzoek niet gebruikt kan worden voor de opgegeven Request URI.
406-Not Acceptable: Geeft aan dat de bron die door de variabele Request URI wordt gespecificeerd met geen van de gegevenstypes die in de Accept-header van het verzoek gespecificeerd zijn overeenkomt.
407-Proxy Authentication Required: Geeft aan dat de client zijn authenticiteit moet aantonen bij een proxyserver voordat hij toegang krijgt tot de opgevraagde bron.
408-Request Timeout: Geeft aan dat de client geen verzoek heeft ingediend binnen de verstrijkingstermijn van de server.
409-Conflict: Geeft aan dat het verzoek niet verwerkt kon worden vanwege een conflict met de huidige staat van de opgevraagde bron, wanneer bijvoorbeeld een opdracht PUT probeert om gegevens naar een bron te schrijven die al gebruikt is.
410-Gone: Geeft aan dat de opgevraagde bron niet langer beschikbaar is op de server en dat de server geen alternatieve locatie kent.
411-Length Required: Geeft aan dat de server geweigerd heeft een verzoek te verwerken dat geen Content-Length header heeft.
412-Precondition Failed: Geeft aan dat de server er niet in geslaagd is aan een van de eerste voorwaarden die in de header van het verzoek is gespecificeerd, tegemoet te komen.
413-Request URI Too Long: Geeft aan dat de server weigert een verzoek te verwerken omdat de waarde van Request URI langer is dan de server bereid is te verwerken.
415-Unsupported Media Type: Geeft aan dat de server weigert een verzoek te verwerken omdat het verzoek in een indeling is die niet ondersteund wordt door de opgevraagde bron voor de opgevraagde methode.
416-Request Range Not Satisfiable: Geeft aan dat de server een verzoek niet kan verwerken omdat de gegevens die in de Range header zijn gespecificeerd niet bestaan in de opgevraagde bron.
417-Expectation Failed: Geeft aan dat de server niet aan de vereisten kon voldoen die opgegeven zijn in de Expect-header van het verzoek.
Server error codes
500-Internal Server Error: Geeft aan dat de server een onverwachte voorwaarde is tegengekomen die tegemoetkoming aan het verzoek verhinderd heeft.
501-Not Implemented: Geeft aan dat de server niet over de functionaliteit beschikt die nodig is om aan het verzoek te kunnen voldoen.
502-Bad Gateway: Geeft aan dat de gateway of proxyserver een ongeldige reactie heeft ontvangen van een bovenstroomse server tijdens een poging het verzoek te verwerken.
503-Service Unavailable: Geeft aan dat de server het verzoek niet heeft verwerkt omdat deze tijdelijk overbelast is of onderhouden wordt.
504-Gateway Timeout: Geeft aan dat een gateway of proxyserver geen tijdige reactie heeft ontvangen van de upstream server die in de URI gespecificeerd is of van een andere ondersteunende server die nodig was om het verzoek af te handelen.
505-HTTP Version Not Supported: Geeft aan dat de server de gebruikte HTTP protocolversie uit het verzoek niet kan of wil ondersteunen.
Houd je klaar voor een hele lange post
:Deel1:
HyperText Transfer Protocol (HTTP)
1. Inleiding
Het idee achter het HTTP-protocol waarmee clients en servers met elkaar praten, is ontwikkeld door mensen van het CERN (Europees Centrum voor Nuclair Onderzoek) in Geneve.
Toen zij hun onderzoek over het delen van documenten tussen computers hadden afgerond, gaven ze het project over aan een Amerikaanse Universiteit (NSCA).
2. Wat is HTTP?
HTTP (Hypertext Transfer Protocol) is een TCP/IP-applicatielaagprotocol en omvat regels of protocollen die zorgen dat webpagina’s via verschillende computers geraadpleegd kunnen worden. Dit gebeurt wanneer je een adres in de browser invoert of je op een link klikt. Het protocol is verdeeld in twee delen: de vraag van de client en het antwoord van de server.
3. Begrippen
Cliënt/server
De cliënt is het programma waarmee aan de server wordt bericht dat er een bepaald proces moet worden uitgevoerd, bijvoorbeeld het laten zien van een website.
De server is het programma dat het proces uitvoert. Op internet zoeken de gebruikers meestal met een cliënt op het eigen systeem, zoals de browser, naar een server die ergens op internet actief is.
Communicatie tussen beiden gebeurt via TCP/IP, wat het vorig trimester uitgebreid aan bod kwam.
Directory
Een website heeft op een computer of webserver altijd een eigen directory. In deze directory komen alle bestanden te staan die via internet opvraagbaar moeten zijn. Dat zijn dus de webpagina's (HTML bestanden), afbeeldingen die op de webpagina’s staan enz.
Verschillende benamingen kunnen onder andere “home directory”, “website directory”, “root”, “web root”, ... zijn.
HTTP-versies
We onderscheiden 2 versies HTTP: HTTP1.0 en het recentere (en betere) HTTP1.1
Er zijn 3 belangrijke verschillen:
- Er wordt één verbinding opengehouden om alles door te sturen, waar bij versie 1.0 voor alles afzonderlijk (afbeeldingen, tekst,...) een apparte verbinding wordt gemaakt met de server.
- Tekst kan gecomprimeerd worden, wat de snelheid bevordert.
- ...
4. Het tot stand brengen van een verbinding
Tenzij de gebruiker of de hyperlink het IP-adres van de server specifieert, is de eerste stap in het tot stand brengen van een verbinding tussen twee systemen het achterhalen van het adres door een name resolution-verzoek naar een DNS-server te versturen.
Met dit adres kan het IP-protocol verkeer naar de server dirigeren.
Als de cliënt dit adres eenmaal weet, zal deze een TCP-verbinding met poort 80 van de server maken.
Nu is de TCP-verbinding tot stand gekomen en kunnen browser en server HTTP-berichten uitwisselen. Deze berichten bestaan uit 2 berichttypes: HTTP-verzoeken en HTTP-aanvragen. Deze twee berichttypes kan je dan nog eens opsplitsen in de volgende elementen:
- start line: Bevat een verzoekopdracht of reply status indicator, en enkele variabelen.
- headers: Bevatten een serie velden met informatie over het bericht of het systeem waar het afkomstig van is.
- empty line: Een witregel die het einde van de header aangeeft.
- message body: bevat de inhoud die naar het andere systeem verzonden wordt.
5. HTTP-verzoeken
De beginregel van een HTTP-verzoek ziet er als volgt uit:
Request Type - Request URI - HTTP Versie
5.1 Request Type
Er zijn acht types van verzoekberichten of request types:
get; head; post; options; put; delete; trace; connect
We bespreken even de 2 belangrijkste:
GET: Het grootste deel van de HTTP-verzoeken bestaat uit dit type verzoek.
Dit bevat een verzoek naar informatie die in de request URI(zie verder) is gespecifieerd.
POST: Vraagt aan dat de informatie in de message body door het doelsysteem geaccepteerd wordt als ondergeschikt aan de bron die in de request URI is beschreven.
Request URI
Request URI is een variabele en bevat een Uniform Resource Identifier. Dit is een tekenreeks die specifiek verwijst naar een unieke bron op het doelsysteem. Deze variabele kan bijvoorbeeld de naam bevatten van een bestand op de webserver dat de cliënt van deze server wenst te ontvangen, of de naam van de directory waaruit de server dit bestand moet versturen. De variabele HTTPversion gaat na welke HTTP-versie door het systeem
ondersteund wordt.
Dus als je nu als gebruiker de naam van een website invoert in je browser, zal het verzoekbericht er als volgt uitzien:
GET / HTTP/1.1
De opdracht GET verzoekt de server een bestand te sturen. De “/” verwijst naar de directory van de website, zodat de webserver kan antwoorden door het standaardbestand uit zijn homedirectory door te sturen.
6. HTTP-antwoorden
De basiselementen van HTTP-antwoorden, gegenereerd door de webserver, bevatten veel dezelfde elementen als van de verzoeken. De beginregel bestaat uit:
HTTPVersion StatusCode StatusPhrase
HTTP Version: Verwijst naar de standaard die door de server wordt ondersteund.
Status Code/Status Phrase: Gaat na of de server het verzoek succesvol verwerkt heeft, met de nodige uitleg erbij. De code is een getal van 3 cijfers en de Status Phrase bestaat uit strings.
De codewaardes zijn gedefinieerd in de HTTP-specificatie en worden door alle webserveruitvoeringen eenduidig gebruikt. Het eerste cijfer van de code specifieert de algemene aard van het antwoord en de andere twee geven wat meer uitleg over de code.
Ook al wordt de status phrase eveneens gedefinieerd in de specificatie, bij sommige webserverproducten kan je de tekststring aanpassen om meer informatie aan de cliënt te verstrekken. We geven een overzicht van de codes en phrases:
6.1 Informational Codes (1xx)
Dit type bevat maar 1 code en wordt gebruikt in antwoorden zonder message body.
100-Continue
6.2 Successful Codes (2xx)
Geven aan dat het verzoek van de cliënt ontvangen, begrepen en geaccepteerd is.
200-OK; 201-Created; 202-Accepted; 203-Nonauthoritative Information;
204-No Content; 205-Reset Content; 206-Partial Content
6.3 Redirection Codes (3xx)
Geeft aan dat om een verzoek te kunnen verwerken, er een volgende handeling van de client nodig is.
300-Multiple Choices; 301-Moved Permanently; 302-Found; 303-See Other;
304-Not Modified; 305-Use Proxy; 306-Unused; 307-Temporary Redirect
6.4 Client Error Codes (4xx)
Door een fout van de client kan het verzoek niet worden verwerkt.
400-Bad Request; 401-Unauthorized; 402-Payment Required; 403-Forbidden;
404-Not Found; 405-Method Not Allowed; 406-Not Acceptable;
407-Proxy Authentication Required; 408-Request Timeout; 409-Conflict; 410-Gone;
411-Length Required; 412-Precondition Failed; 413-Required Entity Too Large;
414-Required URI Too Long; 415-Unsupported Media Type;
416-Requested Range Not Satisfiable; 417-Expectation Failed
6.5 Server Error Codes (5xx)
Een verzoek kon niet verwerkt worden door een fout bij de server.
500-Internal Server Error; 501-Not Implemented; 502-Bad Gateway;
503-Service Unavailable; 504-Gateway Timeout; 505-HTTP Version Noy Supported
7. HTTP-headers
Na de beginregel of start line kan elk HTTP-bericht eventueel een serie headers bevatten. Deze bestaan uit strings en worden op deze manier ingedeeld:
Fieldname: Fieldvalue
Fieldname: Deze variabele geeft het type informatie aan dat in de header opgenomen is.
Fieldvalue: Deze bevat de informatie zelf.
De verschillende headers leveren informatie over het systeem en het verzoek waar het bericht vandaan komt. Daar kan de server gebruik van maken als deze een antwoord samenstelt. De cliënt bepaalt zelf de keuze, het aantal en volgorde van de headers, maar de HTTP-specificatie raadt aan dat dit op basis van 4 categorieën wordt geordend.
We bespreken even de 4 mogelijke waarden voor de variabele Fieldname.
Uitleg bij de waarden vind je terug in de bijlagen.
7.1 Algemene headervelden
Deze headervelden zijn toepasbaar zowel voor de aanvragen als voor de verzoeken, maar niet voor het bestand of andere informatie in de body van het bericht (entity).
De waarden voor de algemene header Fieldname zijn:
Cache-Control; Connection; Date; Pragma; Trailer; Transfer-Encoding; Upgrade; Via, Warning
7.2 Request headervelden
Deze zijn alleen van toepassing op verzoekberichten en bevatten informatie over het verzoek en systeem waarvan dit afkomstig is. Waarden zijn:
Accept; Accept-Charset; Accept-Encoding; Accept-Language; Authorization; Expect; From; Host; If-Match; If-Modified-Since; If-None-match; If-Range; If-Unmodified-Since; Max-Forwards; Proxy-Authorization; Range; Refer; TE; User Agent
7.3 Response headervelden
Deze headers zijn alleen van toepassing op antwoordberichten en bevatten informatie over meldingen en de server die deze heeft gegenereed. De response header Fieldname kan volgende waarden bevatten:
Accept-Ranges; Age; Etag; Location; proxy-Authenticate; Retry-After; Server; Vary; WWW-Authenticate
7.4 Entity headervelden
Entity beschrijft gegevens van de message body van een antwoorden geeft aanvullende informatie over deze gegevens. Waarden kunnen zijn:
Allow; Content-Encoding; Content-Language; Content-Length; Content-Location; Content-MD5; Content-Range; Content-Type; Expires; Last-Modified; Extension-Header
8. Tot slot
De headersectie wordt door een witregel afgesloten en daarna volgt de body van het bericht. Dit bevat de inhoud van het bestand waar de client om gevraagd heeft. Als het bestand groter is dan de maximale inhoud van het pakket, dan genereert de server aanvullende antwoordberichten zonder headers, alleen message bodies.
Request Types
Get: Bevat een verzoek om informatie die in de Request URI gespecifieerd is. Het grootste deel van de verzoekberichten betreft dit type verzoeken.
Head: Functioneel identiek aan het Get-verzoek, behalve dat het antwoord alleen een start line en headers bevat, geen message body.
Post: Vraagt aan dat de informatie in de message body door het doelsysteem geaccepteerd wordt als ondergeschikt aan de bron die in de Request URI is opgegeven.
Options: Bevat een verzoek naar informatie over de opties voor communicatie die beschikbaar zijn in de verzoek/antwoordketen die in de variabele RequestURI is opgegeven.
Put: Vraagt aan dat de informatie die in de message body is bijgesloten wordt opgeslagen door het doelsysteem op de locatie die in de Request URI is gespecifieerd.
Delete: Vraagt aan dat het doelsysteem de bron verwijdert die wordt opgegeven in de variabele Request URI.
Trace: Vraagt aan dat het doelsysteem een applicatielaagloopback uitvoert op het inkomende bericht en dit terugzendt naar de afzender.
Connect: Gereserveerd voor het gebruik met proxyservers die SSL-tunneling leveren.
Algemene headervelden
Cache-Control: bevat aanwijzingen die opgevolgd moeten worden door cachingmechanismen op het doelsysteem.
Connection: Specifieert de opties die voor de huidige verbinding gewenst zijn, zodat het in stand wordt gehouden voor gebruik met meerdere aanvragen.
Date: Specifieert de datum en de tijd waarop het bericht gegenereerd is.
Pragma: Specifieert aanwijzingen die uitdrukkelijk voor de client –of serveruitvoering zijn.
Trailer: Geeft aan dat specifieke headervelden aanwezig zijn aan het einde van een bericht met gecomprimeerde transfercodering.
Transfer-Encoding: Specificeert welk type transformatie is toegepast (als dit het geval is) op de message body om deze veilig naar de bestemming te verzenden.
Upgrade: Specificeert aanvullende communicatieprotocollen die door de client ondersteund worden.
Via: Geeft de gateway- en de proxyservers tussen de client en de server aan en de protocollen die ze gebruiken.
Warning: Bevat aanvullende informatie over de status of transformatie van een bericht.
Request headervelden
Accept: Specificeert de mediatypen die in het antwoordbericht geaccepteerd worden.
Accept-Charset: Specificeert de inhoudscodering die in het antwoordbericht geaccepteerd worden.
Accept-Encoding: Specificeert de inhoudscodering die in het antwoordbericht geaccepteerd worden.
Accept-Language: Specificeert de talen die in het antwoordbericht geaccepteerd worden.
Authorization: Bevat gegevens waarmee op de server de authenticiteit van de client vastgesteld zal worden.
Expect: Specificeert het gedrag dat de client van de server verwacht.
From: Bevat een e-mailadres van de gebruiker die het verzoek genereerde.
Host: Specificeert de hostnaam op internet van de bron waarom verzocht is (meestal een URL), plus een poortnummer als er een andere dan de standaardpoort 80 gebruikt wordt.
If-Match: Wordt gebruikt om een specifiek verzoek voorwaardelijk te maken door specifieke entity-tags te vergelijken.
If-Modified-Since: Wordt gebruikt om een specifiek verzoek voorwaardelijk te maken door de verwijzingsdatum van de ingang in de cache van de client waar de bron zich bevindt te specificeren, welke de server vergelijkt met de feitelijke bron en beantwoordt met ofwel de bron ofwel de cacheverwijzing.
If-None-Match: Wordt gebruikt om een specifiek verzoek voorwaardelijk te maken door specifieke entity-tags niet te vergelijken.
If-Range: Verzoekt de server delen van een entity te verzenden die de client mist.
If-Unmodified-Since: Wordt gebruikt om een specifiek verzoek conditioneel te maken door een datum op te geven die de server moet gebruiken om te bepalen of de verzochte bron geleverd moet worden.
Max-Forwards: Stelt een limiet aan het aantal proxies of gateways dat een verzoek naar een andere server kunnen doorsturen.
Proxy-Authorization: Bevat gegevens waarmee de client zijn authenticiteit bij een proxyserver bewijst.
Range: Bevat één of meerdere bytereeksen die delen van de bron voorstellen die in de Resource URI gespecificeerd zijn en waarvan de client de server vraagt deze te verzenden.
Refer: Specificeert de bron waarvan de waarde Resource URI verkregen is.
TE: Specificeert welke extension transfercoderingen de client kan accepteren in het antwoord en of de client trailer fields met gecomprimeerde transfercodering zal accepteren.
User-Agent: Bevat informatie over de browser die het verzoek heeft ingediend.
Response headervelden
Accept-Ranges: Maakt het de server mogelijk om aan te geven of het range-aanvragen van een bron accepteert (alleen in antwoorden).
Age: Specificeert de verstreken tijd sinds een gecached antwoord door een server is gegenereerd.
Etag: Specificeert de huidige waarde van de entity-tag van de gevraagde variant.
Location: Stuurt het doelsysteem naar een andere locatie van de gevraagde bron dan de in de variabele Request URI genoemde locatie.
Proxy-Authenticate: Specificeert het authenticatiesysteem dat door een proxyserver gebruikt wordt.
Retry-After: Specificeert hoe lang een gevraagde bron onbeschikbaar voor de client zal blijven.
Server: Identificeert de webserversoftware die het verzoek verwerkt heeft.
Vary: Specificeert de headervelden die gebruikt zijn om te bepalen of een client een gecached antwoord zonder revalorisatie van de server kan gebruiken als reactie op een verzoek.
WWW-authenticate: Specificeert het type authenticatie dat vereist is voor de client om toegang tot de gevraagde bron te krijgen.
Entity headervelden
Allow: Specificeert het verzoektype dat door een bron ondersteund wordt die door een specifieke waarde van de Request URI wordt aangewezen.
Content-Encoding: Specificeert aanvullende inhoud-coderingsmechanismen die op de gegevens in de body van een bericht zijn toegepast.
Content-Language: Specificeert de taal van de message body.
Content-Length: Specificeert de lengte van de message body, in bytes.
Content-Location: Specificeert de locatie waar de informatie in de message body van ontleend is, als deze niet gelijk is aan de locatie die in de Resource URI is opgegeven.
Content-MD5: Bevat een MD5-samenvatting van de message body (zoals in RFC-1864 gedefinieerd is) die op de bestemming gebruikt zal worden om de integriteit te verifiëren.
Content-Range: Identificeert de locatie van de gegevens in de message body binnen het geheel van de gevraagde bron, als het bericht alleen een deel van de bron bevat.
Content-Type: Specificeert het mediatype van de gegevens in de message body.
Expires: Specificeert de datum en de tijd waarna het antwoord in de cache als verouderd wordt beschouwd.
Last-Modified: Specificeert de datum en de tijd waarop de gevraagde bron volgens de server voor het laatst is aangepast.
Extension-Header: Maakt het gebruik van aanvullende headervelden mogelijk die zowel door de client als de server moeten worden erkend.
Informational codes
100-Continue: Geeft aan dat het verzoek door de server ontvangen is en dat de client of een ander bericht moet sturen om het verzoek te completeren of op een antwoord moet blijven wachten. Een antwoord met deze code moet gevolgd worden door een ander antwoord met daarin een code waarin de voltooiing van het verzoek wordt aangegeven.
Successful codes
200-OK: Geeft aan dat het verzoek met succes verwerkt is en dat het antwoord de juiste gegevens bevat voor het type verzoek.
201-Created: Geeft aan dat het verzoek met succes verwerkt is en dat een nieuwe bron is gemaakt.
202-Accepted: Geeft aan dat het verzoek voor verwerking geaccepteerd is, maar dat nog niet met de verwerking is begonnen.
203-Nonauthoritative Information: Geeft aan dat de informatie in de headers niet de definitieve informatie is die door de server verstrekt zal worden, maar dat deze van een lokale kopie of van een kopie van derden verzameld zal worden.
204-No Content: Geeft aan dat het verzoek met succes verwerkt is, maar dat het antwoord geen message body bevat. Het kan wel headerinformatie bevatten.
205-Reset Content: Geeft aan dat het verzoek met succes verwerkt is, en dat de clientbrowser de documentweergave moet vernieuwen. Dit bericht betekent meestal dat de gegevens uit een formulier ontvangen zijn en dat de browser de weergave moet vernieuwen door de formuliervelden leeg te maken.
206-Partial Content: Geeft aan dat het verzoek met succes verwerkt is en dat de server een verzoek beantwoord heeft dat de Range header gebruikt om delen van een bron te specificeren.
Redirection codes
300-Multiple Choices: Geeft aan dat het antwoord een lijst met bronnen bevat die gebruikt kunnen worden om aan het verzoek te voldoen en waar de gebruiker er een van moet kiezen.
301-Moved Permanently: Geeft aan dat een nieuwe URI aan de gevraagde bron is toegewezen en dat alle toekomstige referenties aan deze bron een van de nieuwe URI’s moet gebruiken die in het antwoord zijn opgenomen.
302-Found: Geeft aan dat de gevraagde bron tijdelijk onder een andere URI te vinden is, maar dat de client dezelfde waarde voor Request URI moet blijven gebruiken bij toekomstige aanvragen omdat de locatie opnieuw kan veranderen.
303-See Other: Geeft aan dat het antwoord op het verzoek onder een andere URI kan worden gevonden en dat de client een nieuw verzoek aan deze URI moet richten.
304-Not Modified: Geeft aan dat de versie van de opgevraagde bron in de cache van de clien identiek is aan die op de server en dat het opnieuw verzenden van de bron niet nodig is.
305-Use Proxy: Geeft aan dat de opgevraagde bron via de proxy die in de Location header wordt genoemd moet worden benaderd.
306-Unused
307-Temporary Redirect: Geeft aan dat de gevraagde bron tijdelijk onder een andere URI te vinden is, maar dat de client dezelfde waarde voor Request URI moet blijven gebruiken bij toekomstige aanvragen omdat de locatie opnieuw kan veranderen.
Client error codes
400-Bad Request: Geeft aan dat de server het verzoek niet begrepen heeft ten gevolge van een foutieve syntaxis.
401-Unauthorized: Geeft aan dat de server een verzoek niet kon verwerken omdat gebruikersauthenticatie vereist is.
402-Payment Requiered: Gereserveerd voor toekomstig gebruik.
403-Forbidden: Geeft aan dat de server weigert het verzoek te verwerken en dat dit niet herhaald moet worden.
404-Not Found: Geeft aan dat de server de bron die door de variabele Request URI wordt gespecificeerd niet heeft kunnen vinden.
405-Method Not Allowed: Geeft aan dat het type verzoek niet gebruikt kan worden voor de opgegeven Request URI.
406-Not Acceptable: Geeft aan dat de bron die door de variabele Request URI wordt gespecificeerd met geen van de gegevenstypes die in de Accept-header van het verzoek gespecificeerd zijn overeenkomt.
407-Proxy Authentication Required: Geeft aan dat de client zijn authenticiteit moet aantonen bij een proxyserver voordat hij toegang krijgt tot de opgevraagde bron.
408-Request Timeout: Geeft aan dat de client geen verzoek heeft ingediend binnen de verstrijkingstermijn van de server.
409-Conflict: Geeft aan dat het verzoek niet verwerkt kon worden vanwege een conflict met de huidige staat van de opgevraagde bron, wanneer bijvoorbeeld een opdracht PUT probeert om gegevens naar een bron te schrijven die al gebruikt is.
410-Gone: Geeft aan dat de opgevraagde bron niet langer beschikbaar is op de server en dat de server geen alternatieve locatie kent.
411-Length Required: Geeft aan dat de server geweigerd heeft een verzoek te verwerken dat geen Content-Length header heeft.
412-Precondition Failed: Geeft aan dat de server er niet in geslaagd is aan een van de eerste voorwaarden die in de header van het verzoek is gespecificeerd, tegemoet te komen.
413-Request URI Too Long: Geeft aan dat de server weigert een verzoek te verwerken omdat de waarde van Request URI langer is dan de server bereid is te verwerken.
415-Unsupported Media Type: Geeft aan dat de server weigert een verzoek te verwerken omdat het verzoek in een indeling is die niet ondersteund wordt door de opgevraagde bron voor de opgevraagde methode.
416-Request Range Not Satisfiable: Geeft aan dat de server een verzoek niet kan verwerken omdat de gegevens die in de Range header zijn gespecificeerd niet bestaan in de opgevraagde bron.
417-Expectation Failed: Geeft aan dat de server niet aan de vereisten kon voldoen die opgegeven zijn in de Expect-header van het verzoek.
Server error codes
500-Internal Server Error: Geeft aan dat de server een onverwachte voorwaarde is tegengekomen die tegemoetkoming aan het verzoek verhinderd heeft.
501-Not Implemented: Geeft aan dat de server niet over de functionaliteit beschikt die nodig is om aan het verzoek te kunnen voldoen.
502-Bad Gateway: Geeft aan dat de gateway of proxyserver een ongeldige reactie heeft ontvangen van een bovenstroomse server tijdens een poging het verzoek te verwerken.
503-Service Unavailable: Geeft aan dat de server het verzoek niet heeft verwerkt omdat deze tijdelijk overbelast is of onderhouden wordt.
504-Gateway Timeout: Geeft aan dat een gateway of proxyserver geen tijdige reactie heeft ontvangen van de upstream server die in de URI gespecificeerd is of van een andere ondersteunende server die nodig was om het verzoek af te handelen.
505-HTTP Version Not Supported: Geeft aan dat de server de gebruikte HTTP protocolversie uit het verzoek niet kan of wil ondersteunen.
zukketwuk
Legacy Member
Hier deel 2, specifiek over tunneling:
Wat is tunneling :
Tunneling is het verzenden van een data protocol verpakt in een ander protocol. Deze techniek wordt vaak toegepast met encryptie.
Tunnelen doen we omdat
niet door de onderliggende infrastructuur gerouteerd kan worden
niet door de onderliggende infrastructuur gerouteerd mag worden
Er is niets op tegen om een reeds ingepakt pakketje voor een tweede maal in te pakken. Tunnels in tunnels zorgen uiteindelijk wel voor een afname aan efficiency, doordat de pakketjes een steeds kleinere payload en een grotere hoeveelheid overhead met zich meedragen. Je zal dan meer pakketjes moeten transporteren om dezelfde hoeveelheid informatie over te brengen.
Tunneling bestaat in principe uit drie stappen.
De eerste stap is het inkapselen en encrypten van de data in het desbetreffende tunneling protocol. Dit zal worden gedaan door een host die tussen het privé –en publieke netwerk bevindt.
De volgende stap is het daadwerkelijk versturen van de zojuist gevormde data pakketjes over het publieke netwerk. Deze zullen door tussenliggende routers naar hun eindbestemming worden geleid.
De laatste stap is voor de ontvangende host om het ingekapselde pakketje vrij te maken van het encapsulation protocol en de originele data bloot te leggen. Dit wordt gedaan door de host aan de andere kant van het netwerk die zich ook weer tussen het prive- en publieke netwerk bevind. Dit is een algemene blik op tunneling, per protocol verschilt dit enigszins.
Tunneling vereisten
Om aan tunneling moet je natuurlijk gebruik maken van een tunneling protocol.
Een tunneling protocol bepaalt de regels waarop de drie stappen voor het opzetten van de tunnel worden doorlopen. Er zijn een aantal vereisten aan een tunnel die van belang zijn bij het bespreken van de verschillende protocollen.
• Authentication
• Access control
• Confidentiality
• Data integrity
Authenticatie: dit wil zeggen dat voordat de beveiligde verbinding is opgezet, elke host zich moet verzekeren van de identiteit van de andere host. Om een voorbeeld te noemen, sommige protocollen verzorgen authenticatie op gebruikersniveau, een bepaald persoon dient zich dus te authenticeren (PPTP). Andere protocollen verzekeren authenticatie juist weer op het niveau van de computer zelf (IPSec).
Access control: wanneer iemand zich eenmaal geauthenticeerd heeft moet deze persoon de juiste rechten krijgen. Met andere woorden er moet bepaald worden wat deze persoon wel en wat niet mag doen.
Confidentiality: Wanneer deze persoon zich eenmaal geauthenticeerd heeft en de juiste rechten heeft toegewezen gekregen kan hij data gaan versturen over de vpn- verbinding. Confidentiality wil zeggen dat de verstuurde data niet kan worden gelezen door mensen die proberen de data te onderscheppen. Dit wordt bereikt door middel van data encryptie. Belangrijker is welke methode van encryptie wordt gebruikt. Dit verzekerd integriteit van de data. Hier komt naar voren dat key-management zeer belangrijk is. De desbetreffende sleutels worden tussen de communicerende gecreëerd en gedeeld om encryptie en decryptie te verzorgen. Key management bevat zaken als hoe er overeenstemming over de sleutels plaatsvindt en hoe deze vernieuwd worden.
Data integrity: dit wil zeggen dat de data die verstuurd wordt naast dat die niet kan worden gelezen dat deze ook niet kan worden veranderd. Dit kan gedaan worden door aan het begin een unieke hash/checksum te maken van de data en deze aan het eind te controleren of deze nog hetzelfde is. Een ander mogelijkheid is of het tunneling protocol wel of niet data compressie toepast. Ook in data compressie zelf zitten weer verschillen in het gebruikte algoritme.
Een ander vereiste is dat een tunneling protocol kan samenwerken met andere netwerk protocollen. Dit is van belang omdat protocollen sterk onderhevig zijn aan veranderingen. Dit verhoogt de flexibiliteit van het protocol.
Waar worden tunnels gebruikt:
Tunnels worden vaak gebruikt om veilige toegang te verschaffen tussen één of meerdere lokaties in de vorm van een VPN (virtual private network). Een VPN is een eigen, afgesloten datanetwerk dat door één of meerdere bedrijven (meestal bedrijven) wordt gebruikt, dat onderliggend gebruikmaakt van een publiek netwerk als het Internet. Een VPN komt tot stand middels het gebruik van versleutelingstechnieken, of tunneling protocollen, zodat een verbinding niet kan worden afgeluisterd. Ook wordt er authenticatie toegepast om er zeker van te zijn dat degene die gebruik maakt van het VPN daartoe gerechtigd is en message integrity, om te voorkomen dat berichten worden aangepast. Op deze manier kan een beveiligd netwerk draaien over een in principe onveilig netwerk.
VPN en bedrijven.
Waarom maken bedrijven zo vaak gebruik van een VPN? Het antwoord ligt voor de hand: het is goedkoop en geeft een hoog gebruiksgemak. Voor personeel op verplaatsing, zeker in het buitenland, is het niet meer nodig een dure telefoonverbinding op te bouwen met een bedrijfsserver om toegang te krijgen tot uw netwerk. Het personeelslid kan lokaal inloggen op het internet en dan een VPN-verbinding leggen naar de bedrijfsserver (indien u gebruikt maakt van een constante internetverbinding zoals ADSL of kabel komen er zelfs helemaal geen telefoonkosten meer aan te pas).
Ook voor bedrijven kan een VPN flink wat goedkoper uitvallen. Zo is het over het algemeen erg duur om twee filialen van een bedrijf (of een filiaal en het hoofdkantoor) met elkaar te verbinden via een huurlijn. Een huurlijn die enkel dient voor internet is flink wat goedkoper. Dat heeft te maken met de afstand die overbrugd moet worden. Delen van een bedrijf liggen meestal verder uit elkaar dan wat overbrugd zou moeten worden voor een huurlijn naar een internetknooppunt. En soms is het gewoon ondoenbaar. Bijvoorbeeld: een filiaal in Brussel dat verbonden moet worden met een hoofdkantoor in New York. Een VPN is hiervoor onmiskenbaar de goedkoopste oplossing.
Ten slotte kan een VPN ook nog kostenbesparend werken inzake hardware-investeringen, omdat u voor de privé netwerktoegang en de internettoegang nu nog maar één aansluitpunt en één stel communicatie-apparatuur nodig hebt in plaats van twee of meer.
Kort samengevat:
In elk lokaal netwerk (LAN) wordt een firewall geplaatst. Deze stuurt gegevens die voor één van de niet-lokale computers bestemd zijn geëncrypteert door.
Een VPN (Virtual Private Network) is een systeem dat het mogelijk maakt om geografisch
verspreide computers via het internet te verbinden tot een ’virtueel’ lokaal netwerk. Alle
communicatie is geëncrypteerd, zodat onbevoegden de gegevens niet kunnen onderscheppen. Een VPN is bijvoorbeeld bruikbaar als uw organisatie geografisch verspreid is. Bijvoorbeeld:
• Met deze techniek is het eveneens mogelijk om met een portable van overal ter wereld via het internet op een beveiligde manier op het bedrijfsnetwerk komen.
VPN Protocollen
Enkele voorbeelden van VPN protocollen zijn:
• IPSec
• PPTP (Microsoft's Point-to-Point Tunneling Protocol)
• L2TP
IPsec protocol
IPsec (Internet Protocol Security) is een standaard protocol voor het beveiligen van Internet Protocol (IP) doormiddel van encryptie en/of authenticatie op alle IP-pakketten. IPSec ondersteund beveiliging vanaf het 3e niveau van de OSI layer, namelijk de network layer. IPsec is een verzameling van cryptografische protocols voor 2 doeleinden,
1) Beveiliging van de pakket stroom
2) Sleutels wisseling
IPsec vergeleken met andere internetbeveiligingsprotocols
IPsec functioneert op de 3e layer van het OSI-protocol, wat het mogelijk maakt om IPsec te gebruiken voor zowel TCP als UDP. Dat betekent dat IPsec zijn hoofd boven water moet houden door te werken aan betrouwbaarheid, flexibiliteit en fragmentatie, vergeleken met transportlayer en de daarboven aanwezige protocollen, zoals SSL (OSI layer 6), die geen UDP kunnen beveiligen. SSL/TLS gebruikt daarentegen OSI layer 4, om zo betrouwbaarheid en fragmentatie te verkrijgen.
OSI-model
Point to Point Tunneling Protocol
Point to Point Tunneling Protocol (afgekort PPTP) is een protocol dat gebruikt wordt binnen een VPN ( Virtueel Private Netwerk). Hierbij wordt een verbinding gemaakt via het internet tussen twee LAN's (Local Area Network) of tussen een PC op het internet en een LAN. Er wordt als het ware een tunnel door het internet gecreëerd waardoor veilig informatie verzonden kan worden. Meestal dient een computer in het ene netwerk als server en de andere als cliënt.
PPTP is een protocol dat vooral door Microsoft sterk gepromoot werd. Het is eigenlijk een uitbereiding van het Point to Point Protocol (afgekort PPP). Dit protocol wordt gebruikt voor om 2 computers met elkaar te verbinden via modems. PPTP gebruikt bijvoorbeeld de authenticatie van PPP. PPTP is beschreven in RFC 2637 .
Er zijn drie stappen nodig om de tunnel te maken. PPP verbinding, PPTP verbinding controle, en PPTP tunneling. De eerste stap is voor de remote client om om een PPP connectie te maken met de ISP. Hierbij zal authenticatie op gebruikersniveau plaatsvinden. Wanneer deze connectie is gemaakt, dan zal deze verbinding worden gecontroleerd door het PPTP protocol. Deze controle zal plaatsvinden door onderling verstuurde controle berichten. Als de controle goed wordt uitgevoerd zal de tunnel worden opgezet en zullen de PPP pakketjes die verstuurd worden geaccepteerd, geëncrypt, en in een IP datagram moeten worden geplaatst. Bij aankomst zullen de pakketjes gedecrypt worden, het originele PPP pakketje onthuld worden en naar de bestemming worden gestuurd over het netwerk. Deze procedure geld voor alle layer 2 protocollen.
L2TP (Layer to tunneling protocol)
L2TP protocol is ontstaan uit twee andere protocollen te weten Layer to forwarding (L2F en PPTP. L2F lijkt heel veel op PPTP. De bedoeling was om met een nieuw protocol te komen, dat de beste eigenschappen van L2F en PPTP samenvoegde.
L2TP is evenzo bovenop het PPP protocol gebouwd, en gebruikt PPP voor authenticatie en encryptie methoden. L2TP protocol is ontworpen voor remote access clients en heeft een tunneling methode die veel weg heeft van PPTP door middel van het inkapselen van PPP pakketjes.
Maar waarin verschilt L2TP van PPTP? Ondanks dat PPTP andere pakketjes van allerlei protocollen kan inkapselen zal het resulterende frame zal altijd over een IP backbone moeten worden verstuurd. Het verschil met L2TP is dat dit protocol dit niet vraagt. L2TP werkt ook over andere netwerken zoals: Frame Relay, X.25 of ATM.
Dit geeft L2TP meer flexibiliteit, dit zal het aantal oplossingen door middel van dit protocol verhogen. PPTP heeft als nadeel dat er maar 1 tunnel tussen twee eindpunten kan worden opgezet. In L2TP kunnen meerdere tunnels tegelijkertijd worden opgezet. L2TP heeft ook de optie om kleinere headers te gebruiken dan PPTP omdat er gebruik wordt gemaakt van header compressie. Wanneer compressie wordt gebruikt ontstaan 4 byte headers tegen 6 byte headers van PPTP.
Als laatste heeft PPTP niet de mogelijkheid tot tunnel authenticatie naast gebruiker authenticatie en L2TP wel.
Tot slot enkele cijfers:
Volgens het onderzoeksbureau IDC zullen de Europese investeringen in virtuele private netwerken tegen 2009 zowat 5,7 miljard dollar bedragen. Het bureau schat dat de Europese groei van VPN's dit jaar tot 30 procent kan oplopen. Een VPN is intussen dus behoorlijk ingeburgerd, ook al verschilt de concrete invulling vaak van geval tot geval.
Proxyserver
Een proxyserver is een server die zich bevindt tussen de computer van een gebruiker en de computer waarop de door de gebruiker gewenste informatie staat. Wil iemand op een computer waarop een proxyserver is ingesteld een andere computer bereiken, dan gebeurt dit niet rechtstreeks, maar via deze proxyserver. Het doel van deze tussenstap is afhankelijk van het type proxyserver.
Mogelijk doel van een proxyserver
• Het filteren van informatie. Zo kan een bedrijf alle werknemers via een proxyserver met internet verbinden en voorkomen dat bepaalde webpagina's door die werknemers bekeken kunnen worden.
• Bovendien kan de proxyserver als (onderdeel van) een firewall de toegang tot computers van werknemers van buitenaf bemoeilijken en zo als beveiliging gebruikt worden.
• Het verbeteren van de prestatie (performance) van een netwerk. In dit geval wordt de proxyserver gebruikt als tijdelijke opslagruimte. Bezoekt persoon X een website, dan wordt een kopie van de bezochte pagina's opgeslagen op de proxyserver. Wil persoon Y daarna dezelfde website bezoeken, dan krijgt hij de eerder gemaakte kopie te zien. Bezoekt Y een nog niet door de proxyserver opgeslagen website, dan wordt alsnog contact opgenomen met de eigenlijke website.
Het voordeel van de laatste methode is dat het netwerk minder vaak contact hoeft te maken met de oorspronkelijke website. Y ontvangt het resultaat mogelijk sneller en het netwerk wordt ontlast. Het nadeel is dat de getoonde informatie mogelijk niet de meest actuele stand van zaken weergeeft.
Veel internetproviders maken gebruik van dit type proxyserver en vragen hun klanten in hun webbrowser een proxyserver in te stellen. Op deze manier kunnen zij het gebruik van bandbreedte beperken en de snelheid van hun dienst vergroten. Of die klant ook daadwerkelijk profiteert van het gebruik van een proxyserver is afhankelijk van de omvang van de proxyserver en van het type websites dat hij bezoekt. Wijkt zijn internetgedrag sterk af van dat van andere klanten, dan is de kans dat de door hem opgevraagde website zich in de cache van de proxyserver bevindt klein en kan deze tussenstap voor hem juist een vertraging opleveren bij het bereiken van zijn doel. Wanneer de verbinding van de proxyserver met de website echter een hogere bandbreedte heeft dan de verbinding tussen proxyserver en client, kan dit alsnog een aanzienlijke snelheidswinst opleveren.
Open proxy's, misbruik, vandalisme en detectie
Zowel webproxy's als andere proxy's worden regelmatig misbruikt door spammers en mensen die op andere manieren misbruik maken van het Internet. Een open proxy is een proxyserver die verbindingen toestaat van clients van willekeurige IP-adressen, met willekeurige Internetresources elders. Een zeer groot deel van de spam die anno 2006 op het Internet verstuurd wordt, is het gevolg van open proxy's. Veelal installeren spammers open proxy's op Microsoft Windows computers met behulp van virussen die voor dit doel zijn ontworpen. Mensen die misbruik maken op IRC netwerken maken ook vaak gebruik van open proxy's om hun identiteit te verhullen.
Omdat het gebruik van open proxy's veelal samenhangt met misbruik van Internetdiensten, is er een aantal manieren ontwikkeld door systeembeheerders om open proxy's te blokkeren van het gebruik van diensten. IRC netwerken zoals de blitzed network testen systemen van clients automatisch voor bekende types van open proxy's. Zo kan ook een mailserver zo geconfigureerd worden, dat deze zenders van emails automatisch test op open proxy's met software zoals Michael Tokarevs proxycheck
Van diverse open proxy's zijn lijsten beschikbaar, die op het Internet worden bijgehouden, zoals die van de DNSBL, Blitzed OPM en CBL.
De ethiek van het automatisch op open proxy's testen van clients is controversieel. Sommige experts, zoals Vernon Schryver, vinden dat dergelijke tests equivalent zijn aan port scans op client hosts van aanvallers. Volgens anderen stemt de gebruiker van de client met de proxyscan in als het verbinding legt met een server die als onderdeel van de service het testen op proxyservers heeft.
Security Associations
Het SA (security associations) concept is fundamenteel voor IP beveiliging. Een SA definieert de manieren van veiligheid die toegepast moeten worden op de pakketjes. Dit zijn zaken als waar gaan de pakketjes naar toe, en wat voor payload dragen deze pakketjes.
Een SA wordt geïdentificeerd aan de hand van drie parameters: het bestemming adres, een veiligheids protocol identifier en een veiligheid parameter index (SPI). Het bestemming adres is het IP adres van het eindpunt van de SA. De SPI is een 32-bit nummer die de bestemming definieert op het locale netwerk. Het security protocol identifier definieert of we te maken hebben met AH of ESP.
De veiligheid services die SA biedt hangt af van het security protocol, de ingestelde opties en de modus waarin SA opereert.
Tunnel mode
Fig 5
Zoals te zien in figuur 5 wordt in tunnel mode het originele IP pakketje de payload van een ander pakketje. Dit gebeurt door middel van inkapseling. De ingekapselde IP header geeft nu aan dat er een security header volgt.
Authentication header (AH)
Het IPSec authentication header protocol maakt authenticatie van afzonderlijke pakketjes mogelijk. Dit wil zeggen het verzorgen van data integrity en data origin authentication voor de payload. Als laatste bied AH anti-replay services om denial of services aanvallen tegen te gaan.
Het belangrijkste mechanisme dat AH gebruikt is de authentication header. Het nieuwe IP pakketje wordt gevormd door het plaatsen van de authentication header na de nieuwe IP header of enigszins aangepaste header.
Fig 6 The authenctication header structuur
Fig 7 AH tunnel mode
In AH tunnel mode wordt een nieuwe IP header gecreëerd voor het nieuwe IP pakket, en de authentication header wordt tussen de orginele en de nieuwe IP header ingeplaatst. Het originele IP pakketje blijft intact en is ingekapseld met het nieuwe IP pakketje. Op deze manier wordt authenticatie over het gehele originele pakketje verkregen. De AH header komt direct na de IP header en bevat hashes van de data en identificatie. De AH beveiligt de bron en bestemming adressen van de IP header.
Het originele IP pakketje blijft geheel intact en bevat de uiteindelijke bestemming en afzender adressen. De nieuwe IP header bevat de afzender –en bestemmingsadressen van de IPSec apparaten waartussen het nieuwe pakketje zijn weg aflegt.
Belangrijk is te melden dat AH geen gebruik maakt van encryptie.
Encapsulation Security protocol (ESP)
ESP verzorgt authenticatie, data confidentiality door middel van encryptie, en optionele anti-replay beveiliging om denial of service aanvallen te weerstaan.
Net zoals bij AH worden ook hier weer extra velden ingevoegd in de IP pakketjes om deze services te bieden. In tegenstelling tot AH zijn de velden verspreid over het IP pakketje. Sommige zitten in de ESP header en sommige in de ESP trailer en één zit in een ESP authentication veld zoals te zien in onderstaande figuur.
Figuur 8: ESP header, trailer en authenticatie structuur
Wanneer authenticatie niet wordt toegepast dan wordt het ESP authentication veld niet toegevoegd. Wanneer encryptie wordt toegepast, wordt alles vanaf het eind van de ESP header tot het eind van de ESP trailer geëncrypt.
ESP tunnel mode
ESP Tunnel mode kapselt het gehele originele IP pakketje in een nieuw IP pakketje. Een nieuwe IP header en ESP header worden toegevoegd aan het begin van het originele pakketje en de ESP trailer en authenticatie velden aan het eind.
Data authenticatie van het originee Data integrity Replay protectie Data confidentiality
AH Ja Ja Ja Nee
ESP Ja Ja Ja Ja
Wat is tunneling :
Tunneling is het verzenden van een data protocol verpakt in een ander protocol. Deze techniek wordt vaak toegepast met encryptie.
Tunnelen doen we omdat
niet door de onderliggende infrastructuur gerouteerd kan worden
niet door de onderliggende infrastructuur gerouteerd mag worden
Er is niets op tegen om een reeds ingepakt pakketje voor een tweede maal in te pakken. Tunnels in tunnels zorgen uiteindelijk wel voor een afname aan efficiency, doordat de pakketjes een steeds kleinere payload en een grotere hoeveelheid overhead met zich meedragen. Je zal dan meer pakketjes moeten transporteren om dezelfde hoeveelheid informatie over te brengen.
Tunneling bestaat in principe uit drie stappen.
De eerste stap is het inkapselen en encrypten van de data in het desbetreffende tunneling protocol. Dit zal worden gedaan door een host die tussen het privé –en publieke netwerk bevindt.
De volgende stap is het daadwerkelijk versturen van de zojuist gevormde data pakketjes over het publieke netwerk. Deze zullen door tussenliggende routers naar hun eindbestemming worden geleid.
De laatste stap is voor de ontvangende host om het ingekapselde pakketje vrij te maken van het encapsulation protocol en de originele data bloot te leggen. Dit wordt gedaan door de host aan de andere kant van het netwerk die zich ook weer tussen het prive- en publieke netwerk bevind. Dit is een algemene blik op tunneling, per protocol verschilt dit enigszins.
Tunneling vereisten
Om aan tunneling moet je natuurlijk gebruik maken van een tunneling protocol.
Een tunneling protocol bepaalt de regels waarop de drie stappen voor het opzetten van de tunnel worden doorlopen. Er zijn een aantal vereisten aan een tunnel die van belang zijn bij het bespreken van de verschillende protocollen.
• Authentication
• Access control
• Confidentiality
• Data integrity
Authenticatie: dit wil zeggen dat voordat de beveiligde verbinding is opgezet, elke host zich moet verzekeren van de identiteit van de andere host. Om een voorbeeld te noemen, sommige protocollen verzorgen authenticatie op gebruikersniveau, een bepaald persoon dient zich dus te authenticeren (PPTP). Andere protocollen verzekeren authenticatie juist weer op het niveau van de computer zelf (IPSec).
Access control: wanneer iemand zich eenmaal geauthenticeerd heeft moet deze persoon de juiste rechten krijgen. Met andere woorden er moet bepaald worden wat deze persoon wel en wat niet mag doen.
Confidentiality: Wanneer deze persoon zich eenmaal geauthenticeerd heeft en de juiste rechten heeft toegewezen gekregen kan hij data gaan versturen over de vpn- verbinding. Confidentiality wil zeggen dat de verstuurde data niet kan worden gelezen door mensen die proberen de data te onderscheppen. Dit wordt bereikt door middel van data encryptie. Belangrijker is welke methode van encryptie wordt gebruikt. Dit verzekerd integriteit van de data. Hier komt naar voren dat key-management zeer belangrijk is. De desbetreffende sleutels worden tussen de communicerende gecreëerd en gedeeld om encryptie en decryptie te verzorgen. Key management bevat zaken als hoe er overeenstemming over de sleutels plaatsvindt en hoe deze vernieuwd worden.
Data integrity: dit wil zeggen dat de data die verstuurd wordt naast dat die niet kan worden gelezen dat deze ook niet kan worden veranderd. Dit kan gedaan worden door aan het begin een unieke hash/checksum te maken van de data en deze aan het eind te controleren of deze nog hetzelfde is. Een ander mogelijkheid is of het tunneling protocol wel of niet data compressie toepast. Ook in data compressie zelf zitten weer verschillen in het gebruikte algoritme.
Een ander vereiste is dat een tunneling protocol kan samenwerken met andere netwerk protocollen. Dit is van belang omdat protocollen sterk onderhevig zijn aan veranderingen. Dit verhoogt de flexibiliteit van het protocol.
Waar worden tunnels gebruikt:
Tunnels worden vaak gebruikt om veilige toegang te verschaffen tussen één of meerdere lokaties in de vorm van een VPN (virtual private network). Een VPN is een eigen, afgesloten datanetwerk dat door één of meerdere bedrijven (meestal bedrijven) wordt gebruikt, dat onderliggend gebruikmaakt van een publiek netwerk als het Internet. Een VPN komt tot stand middels het gebruik van versleutelingstechnieken, of tunneling protocollen, zodat een verbinding niet kan worden afgeluisterd. Ook wordt er authenticatie toegepast om er zeker van te zijn dat degene die gebruik maakt van het VPN daartoe gerechtigd is en message integrity, om te voorkomen dat berichten worden aangepast. Op deze manier kan een beveiligd netwerk draaien over een in principe onveilig netwerk.
VPN en bedrijven.
Waarom maken bedrijven zo vaak gebruik van een VPN? Het antwoord ligt voor de hand: het is goedkoop en geeft een hoog gebruiksgemak. Voor personeel op verplaatsing, zeker in het buitenland, is het niet meer nodig een dure telefoonverbinding op te bouwen met een bedrijfsserver om toegang te krijgen tot uw netwerk. Het personeelslid kan lokaal inloggen op het internet en dan een VPN-verbinding leggen naar de bedrijfsserver (indien u gebruikt maakt van een constante internetverbinding zoals ADSL of kabel komen er zelfs helemaal geen telefoonkosten meer aan te pas).
Ook voor bedrijven kan een VPN flink wat goedkoper uitvallen. Zo is het over het algemeen erg duur om twee filialen van een bedrijf (of een filiaal en het hoofdkantoor) met elkaar te verbinden via een huurlijn. Een huurlijn die enkel dient voor internet is flink wat goedkoper. Dat heeft te maken met de afstand die overbrugd moet worden. Delen van een bedrijf liggen meestal verder uit elkaar dan wat overbrugd zou moeten worden voor een huurlijn naar een internetknooppunt. En soms is het gewoon ondoenbaar. Bijvoorbeeld: een filiaal in Brussel dat verbonden moet worden met een hoofdkantoor in New York. Een VPN is hiervoor onmiskenbaar de goedkoopste oplossing.
Ten slotte kan een VPN ook nog kostenbesparend werken inzake hardware-investeringen, omdat u voor de privé netwerktoegang en de internettoegang nu nog maar één aansluitpunt en één stel communicatie-apparatuur nodig hebt in plaats van twee of meer.
Kort samengevat:
In elk lokaal netwerk (LAN) wordt een firewall geplaatst. Deze stuurt gegevens die voor één van de niet-lokale computers bestemd zijn geëncrypteert door.
Een VPN (Virtual Private Network) is een systeem dat het mogelijk maakt om geografisch
verspreide computers via het internet te verbinden tot een ’virtueel’ lokaal netwerk. Alle
communicatie is geëncrypteerd, zodat onbevoegden de gegevens niet kunnen onderscheppen. Een VPN is bijvoorbeeld bruikbaar als uw organisatie geografisch verspreid is. Bijvoorbeeld:
• Met deze techniek is het eveneens mogelijk om met een portable van overal ter wereld via het internet op een beveiligde manier op het bedrijfsnetwerk komen.
VPN Protocollen
Enkele voorbeelden van VPN protocollen zijn:
• IPSec
• PPTP (Microsoft's Point-to-Point Tunneling Protocol)
• L2TP
IPsec protocol
IPsec (Internet Protocol Security) is een standaard protocol voor het beveiligen van Internet Protocol (IP) doormiddel van encryptie en/of authenticatie op alle IP-pakketten. IPSec ondersteund beveiliging vanaf het 3e niveau van de OSI layer, namelijk de network layer. IPsec is een verzameling van cryptografische protocols voor 2 doeleinden,
1) Beveiliging van de pakket stroom
2) Sleutels wisseling
IPsec vergeleken met andere internetbeveiligingsprotocols
IPsec functioneert op de 3e layer van het OSI-protocol, wat het mogelijk maakt om IPsec te gebruiken voor zowel TCP als UDP. Dat betekent dat IPsec zijn hoofd boven water moet houden door te werken aan betrouwbaarheid, flexibiliteit en fragmentatie, vergeleken met transportlayer en de daarboven aanwezige protocollen, zoals SSL (OSI layer 6), die geen UDP kunnen beveiligen. SSL/TLS gebruikt daarentegen OSI layer 4, om zo betrouwbaarheid en fragmentatie te verkrijgen.
OSI-model
Point to Point Tunneling Protocol
Point to Point Tunneling Protocol (afgekort PPTP) is een protocol dat gebruikt wordt binnen een VPN ( Virtueel Private Netwerk). Hierbij wordt een verbinding gemaakt via het internet tussen twee LAN's (Local Area Network) of tussen een PC op het internet en een LAN. Er wordt als het ware een tunnel door het internet gecreëerd waardoor veilig informatie verzonden kan worden. Meestal dient een computer in het ene netwerk als server en de andere als cliënt.
PPTP is een protocol dat vooral door Microsoft sterk gepromoot werd. Het is eigenlijk een uitbereiding van het Point to Point Protocol (afgekort PPP). Dit protocol wordt gebruikt voor om 2 computers met elkaar te verbinden via modems. PPTP gebruikt bijvoorbeeld de authenticatie van PPP. PPTP is beschreven in RFC 2637 .
Er zijn drie stappen nodig om de tunnel te maken. PPP verbinding, PPTP verbinding controle, en PPTP tunneling. De eerste stap is voor de remote client om om een PPP connectie te maken met de ISP. Hierbij zal authenticatie op gebruikersniveau plaatsvinden. Wanneer deze connectie is gemaakt, dan zal deze verbinding worden gecontroleerd door het PPTP protocol. Deze controle zal plaatsvinden door onderling verstuurde controle berichten. Als de controle goed wordt uitgevoerd zal de tunnel worden opgezet en zullen de PPP pakketjes die verstuurd worden geaccepteerd, geëncrypt, en in een IP datagram moeten worden geplaatst. Bij aankomst zullen de pakketjes gedecrypt worden, het originele PPP pakketje onthuld worden en naar de bestemming worden gestuurd over het netwerk. Deze procedure geld voor alle layer 2 protocollen.
L2TP (Layer to tunneling protocol)
L2TP protocol is ontstaan uit twee andere protocollen te weten Layer to forwarding (L2F en PPTP. L2F lijkt heel veel op PPTP. De bedoeling was om met een nieuw protocol te komen, dat de beste eigenschappen van L2F en PPTP samenvoegde.
L2TP is evenzo bovenop het PPP protocol gebouwd, en gebruikt PPP voor authenticatie en encryptie methoden. L2TP protocol is ontworpen voor remote access clients en heeft een tunneling methode die veel weg heeft van PPTP door middel van het inkapselen van PPP pakketjes.
Maar waarin verschilt L2TP van PPTP? Ondanks dat PPTP andere pakketjes van allerlei protocollen kan inkapselen zal het resulterende frame zal altijd over een IP backbone moeten worden verstuurd. Het verschil met L2TP is dat dit protocol dit niet vraagt. L2TP werkt ook over andere netwerken zoals: Frame Relay, X.25 of ATM.
Dit geeft L2TP meer flexibiliteit, dit zal het aantal oplossingen door middel van dit protocol verhogen. PPTP heeft als nadeel dat er maar 1 tunnel tussen twee eindpunten kan worden opgezet. In L2TP kunnen meerdere tunnels tegelijkertijd worden opgezet. L2TP heeft ook de optie om kleinere headers te gebruiken dan PPTP omdat er gebruik wordt gemaakt van header compressie. Wanneer compressie wordt gebruikt ontstaan 4 byte headers tegen 6 byte headers van PPTP.
Als laatste heeft PPTP niet de mogelijkheid tot tunnel authenticatie naast gebruiker authenticatie en L2TP wel.
Tot slot enkele cijfers:
Volgens het onderzoeksbureau IDC zullen de Europese investeringen in virtuele private netwerken tegen 2009 zowat 5,7 miljard dollar bedragen. Het bureau schat dat de Europese groei van VPN's dit jaar tot 30 procent kan oplopen. Een VPN is intussen dus behoorlijk ingeburgerd, ook al verschilt de concrete invulling vaak van geval tot geval.
Proxyserver
Een proxyserver is een server die zich bevindt tussen de computer van een gebruiker en de computer waarop de door de gebruiker gewenste informatie staat. Wil iemand op een computer waarop een proxyserver is ingesteld een andere computer bereiken, dan gebeurt dit niet rechtstreeks, maar via deze proxyserver. Het doel van deze tussenstap is afhankelijk van het type proxyserver.
Mogelijk doel van een proxyserver
• Het filteren van informatie. Zo kan een bedrijf alle werknemers via een proxyserver met internet verbinden en voorkomen dat bepaalde webpagina's door die werknemers bekeken kunnen worden.
• Bovendien kan de proxyserver als (onderdeel van) een firewall de toegang tot computers van werknemers van buitenaf bemoeilijken en zo als beveiliging gebruikt worden.
• Het verbeteren van de prestatie (performance) van een netwerk. In dit geval wordt de proxyserver gebruikt als tijdelijke opslagruimte. Bezoekt persoon X een website, dan wordt een kopie van de bezochte pagina's opgeslagen op de proxyserver. Wil persoon Y daarna dezelfde website bezoeken, dan krijgt hij de eerder gemaakte kopie te zien. Bezoekt Y een nog niet door de proxyserver opgeslagen website, dan wordt alsnog contact opgenomen met de eigenlijke website.
Het voordeel van de laatste methode is dat het netwerk minder vaak contact hoeft te maken met de oorspronkelijke website. Y ontvangt het resultaat mogelijk sneller en het netwerk wordt ontlast. Het nadeel is dat de getoonde informatie mogelijk niet de meest actuele stand van zaken weergeeft.
Veel internetproviders maken gebruik van dit type proxyserver en vragen hun klanten in hun webbrowser een proxyserver in te stellen. Op deze manier kunnen zij het gebruik van bandbreedte beperken en de snelheid van hun dienst vergroten. Of die klant ook daadwerkelijk profiteert van het gebruik van een proxyserver is afhankelijk van de omvang van de proxyserver en van het type websites dat hij bezoekt. Wijkt zijn internetgedrag sterk af van dat van andere klanten, dan is de kans dat de door hem opgevraagde website zich in de cache van de proxyserver bevindt klein en kan deze tussenstap voor hem juist een vertraging opleveren bij het bereiken van zijn doel. Wanneer de verbinding van de proxyserver met de website echter een hogere bandbreedte heeft dan de verbinding tussen proxyserver en client, kan dit alsnog een aanzienlijke snelheidswinst opleveren.
Open proxy's, misbruik, vandalisme en detectie
Zowel webproxy's als andere proxy's worden regelmatig misbruikt door spammers en mensen die op andere manieren misbruik maken van het Internet. Een open proxy is een proxyserver die verbindingen toestaat van clients van willekeurige IP-adressen, met willekeurige Internetresources elders. Een zeer groot deel van de spam die anno 2006 op het Internet verstuurd wordt, is het gevolg van open proxy's. Veelal installeren spammers open proxy's op Microsoft Windows computers met behulp van virussen die voor dit doel zijn ontworpen. Mensen die misbruik maken op IRC netwerken maken ook vaak gebruik van open proxy's om hun identiteit te verhullen.
Omdat het gebruik van open proxy's veelal samenhangt met misbruik van Internetdiensten, is er een aantal manieren ontwikkeld door systeembeheerders om open proxy's te blokkeren van het gebruik van diensten. IRC netwerken zoals de blitzed network testen systemen van clients automatisch voor bekende types van open proxy's. Zo kan ook een mailserver zo geconfigureerd worden, dat deze zenders van emails automatisch test op open proxy's met software zoals Michael Tokarevs proxycheck
Van diverse open proxy's zijn lijsten beschikbaar, die op het Internet worden bijgehouden, zoals die van de DNSBL, Blitzed OPM en CBL.
De ethiek van het automatisch op open proxy's testen van clients is controversieel. Sommige experts, zoals Vernon Schryver, vinden dat dergelijke tests equivalent zijn aan port scans op client hosts van aanvallers. Volgens anderen stemt de gebruiker van de client met de proxyscan in als het verbinding legt met een server die als onderdeel van de service het testen op proxyservers heeft.
Security Associations
Het SA (security associations) concept is fundamenteel voor IP beveiliging. Een SA definieert de manieren van veiligheid die toegepast moeten worden op de pakketjes. Dit zijn zaken als waar gaan de pakketjes naar toe, en wat voor payload dragen deze pakketjes.
Een SA wordt geïdentificeerd aan de hand van drie parameters: het bestemming adres, een veiligheids protocol identifier en een veiligheid parameter index (SPI). Het bestemming adres is het IP adres van het eindpunt van de SA. De SPI is een 32-bit nummer die de bestemming definieert op het locale netwerk. Het security protocol identifier definieert of we te maken hebben met AH of ESP.
De veiligheid services die SA biedt hangt af van het security protocol, de ingestelde opties en de modus waarin SA opereert.
Tunnel mode
Fig 5
Zoals te zien in figuur 5 wordt in tunnel mode het originele IP pakketje de payload van een ander pakketje. Dit gebeurt door middel van inkapseling. De ingekapselde IP header geeft nu aan dat er een security header volgt.
Authentication header (AH)
Het IPSec authentication header protocol maakt authenticatie van afzonderlijke pakketjes mogelijk. Dit wil zeggen het verzorgen van data integrity en data origin authentication voor de payload. Als laatste bied AH anti-replay services om denial of services aanvallen tegen te gaan.
Het belangrijkste mechanisme dat AH gebruikt is de authentication header. Het nieuwe IP pakketje wordt gevormd door het plaatsen van de authentication header na de nieuwe IP header of enigszins aangepaste header.
Fig 6 The authenctication header structuur
Fig 7 AH tunnel mode
In AH tunnel mode wordt een nieuwe IP header gecreëerd voor het nieuwe IP pakket, en de authentication header wordt tussen de orginele en de nieuwe IP header ingeplaatst. Het originele IP pakketje blijft intact en is ingekapseld met het nieuwe IP pakketje. Op deze manier wordt authenticatie over het gehele originele pakketje verkregen. De AH header komt direct na de IP header en bevat hashes van de data en identificatie. De AH beveiligt de bron en bestemming adressen van de IP header.
Het originele IP pakketje blijft geheel intact en bevat de uiteindelijke bestemming en afzender adressen. De nieuwe IP header bevat de afzender –en bestemmingsadressen van de IPSec apparaten waartussen het nieuwe pakketje zijn weg aflegt.
Belangrijk is te melden dat AH geen gebruik maakt van encryptie.
Encapsulation Security protocol (ESP)
ESP verzorgt authenticatie, data confidentiality door middel van encryptie, en optionele anti-replay beveiliging om denial of service aanvallen te weerstaan.
Net zoals bij AH worden ook hier weer extra velden ingevoegd in de IP pakketjes om deze services te bieden. In tegenstelling tot AH zijn de velden verspreid over het IP pakketje. Sommige zitten in de ESP header en sommige in de ESP trailer en één zit in een ESP authentication veld zoals te zien in onderstaande figuur.
Figuur 8: ESP header, trailer en authenticatie structuur
Wanneer authenticatie niet wordt toegepast dan wordt het ESP authentication veld niet toegevoegd. Wanneer encryptie wordt toegepast, wordt alles vanaf het eind van de ESP header tot het eind van de ESP trailer geëncrypt.
ESP tunnel mode
ESP Tunnel mode kapselt het gehele originele IP pakketje in een nieuw IP pakketje. Een nieuwe IP header en ESP header worden toegevoegd aan het begin van het originele pakketje en de ESP trailer en authenticatie velden aan het eind.
Data authenticatie van het originee Data integrity Replay protectie Data confidentiality
AH Ja Ja Ja Nee
ESP Ja Ja Ja Ja
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.