Nee, doe maar niet, daarmee zet je jezelf alleen maar méér voor schut. Sorry.
Gelukkig heb ik tot dusver enkel feiten gepost, dus met dat voor schut staan zal het wel meevallen.
Excuses aanvaard!
-edit-
Nu ten eerste even iets anders; ff iets helder maken voordat mensen dit alles verkeerd gaan begrijpen... Ik ben bang dat ons gebruik van de term "met wie je praat" verwarring kan veroorzaken.
Aan een ieder die deze discussie leest zonder verstand van encryptie:
De termen "garandeert met wie je praat" die in deze discussie voorbij komen slaan constant enkel op client-server communicatie, dus in situaties als: "ik wil inloggen bij internetbankieren op rabobank.nl. Ben ik wel echt verbonden met rabobank.nl??". Daar garandeert HTTPS dat je verbonden met Rabobank.nl. (En garandeert tevens dat de verbinding versleuteld is, en dus niet af te luisteren valt.)
Echter, bij diensten waarmee je via een server communiceert met iemand anders (eg: chatdienst, e-mail diensten, etc.); dan ongeacht of de verbinding HTTPS beveiligd is of niet heb je
geen garantie dat je werkelijk praat met je gesprekspartner.
Daar kan je enkel zeker van zijn als jij en je gesprekspartner los van de server digitale handtekeningen, andere vormen van hashes of volledige end-to-end encryptie gebruiken. (Met bewezen technieken... Anders is het nog niet controleerbaar. Neem Telegram als voorbeeld hoe het dus
niet moet als je veilig wilt zijn met end-to-end encryptie.)
"Praten" slaat hier dus op HTTPS communicatie tussen je browser en een server (jouw browser "praat" met de server), niet op praten met een persoon terwijl er nog een server tussenzit.
-/edit-
Dan, back to the discussion at hand:
Natuurlijk garandeert het alleen maar dat je praat met wie je denkt te praten. Als het niet encrypted zou zijn, en daarmee eenvoudig af te luisteren - of liever, te manipuleren - valt, dan praat jij niet direct met wie jij denkt te praten.
Neen. Het garandeert dat je praat met wie je denkt te praten,
en encrypt het verkeer. Je krijgt dus "confidentiality", iets dat je niet hebt als je enkel controleert met wie je praat...
Daar zit echt een extreem groot verschil in!
Een wat makkelijker voorbeeld:
Als ik met jou praat in volle trein, dan kunnen anderen dat horen. Maar omdat ik jou zie, weet ik dat ik met jou praat. Ik heb dus absoluut de garantie dat ik daadwerkelijk met jou aan het praten ben; en hoewel er veel mensen zijn is er niemand die de woorden die ik uitpsreek kan veranderen dus is ook de integriteit gewaarborgd. Ik heb echter niet de garantie dat het gesprek vertrouwelijk is!
Dit is vergelijkbaar met een Digital Signature.
Nu anders:
Ik zit alleen met jou in een kamer, er is niemand anders en ook geen afsluiterappartuur oid.
Nu heb ik de garantie dat ik met jou praat, niemand kan mijn woorden wijzigen dus hebben we ook integriteit, en weet ik zeker dat het veilig is omdat niemand ander kan meeluisteren.
... Of we spreken in die volle trein in codetaal die alleen jij en ik kunnen omzetten naar echte taal, dan zitten we wat dichter bij "encryption" in plaats van "secrecy".
Ergo: het feit dat ik de garantie heb met jou te praten, garandeert nog niet dat het ook een vertrouwelijk gesprek is.
Is dat niet even een groot verschil?
In beide situaties heb ik de garantie dat ik met jou praat, maar in de ene situatie is het vertrouwelijk; in de andere niet.
Hetzelfde geldt op het internet; ik kan enkel de garantie hebben met jou te praten, of ik kan de garantie hebben met jou te praten maar dat niemand met ons mee kan luisteren. Dat is een super belangrijk verschil.
Je kan nog altijd praten met wie je denkt te praten terwijl de content zelf niet encrypt is. Dan praat je alsnog met wie je wilt praten en kun je dat prima verifieren, maar kunnen anderen eventueel meeluisteren naar "het gesprek"; cq: de data inzien die jij verstuurd hebt. (Zij kunnen het dan echter niet wijzigen.)
Er zijn andere methoden om dit te controleren zonder dat hier ook encryptie op toegepast wordt... En dat is een zeer belangrijk nuance verschil, zeker als je net wilt doen alsof je uitleg voor de leek is, dan moet je wel zorgen dat het klopt.
Welkom op Tweakers, toch?
Hier, wat leesmateriaal voor je, dan snap je misschien wat ik bedoel. Het verschil tussen encryptie en handtekeningen:
https://en.wikipedia.org/wiki/Digital_signature
http://stackoverflow.com/...-in-asymmetric-encryption
-----
Enkel authenticated = wel de garantie dat het afkomt van de persoon met wie je wilt praten, maar
geen garantie dat die persoon het ook direct aan jou verstuurd heeft (al boeit dat vrij weinig...),
geen garantie dat het bericht is aangepast, en
ook geen garantie dat niemand anders het kan lezen! Je hebt hier dus de garantie dat het bericht daadwerkelijk van de persoon/server afkomt; ongeacht of daar nog iemand tusseninzit of niet.
Voorbeeld situatie:
Ik log in op Tweakers.net en post een reactie. Ik ben authenticated.
Nu wijzigt een Moderator mijn bericht. Maar omdat er geen integriteit controle is, weet niemand zeker of ik wel geschreven heb wat er in die post staat.
En omdat het publiek is, is er ook duidelijk geen encryptie.
Dit is in principe dus wat jij beweert als je zegt dat HTTPS enkel "garandeert met wie je praat"...
Enkel encrypted = wel de garantie dat het niet af te luisteren valt (tot op zekere hoogte, ja.), maar
geen garantie dat je "praat" met wie jij wilt praten! (En dus ook
geen garantie op integriteit, dus geen garantie dat er niet met de data geknoeid is. "Als het encrypted is, dan valt het niet te manipuleren" is dus
absoluut niet waar!
Voorbeeld: twee mensen encrypten een bericht met dezelfde sleutel. Jij hebt de decryptiesleutel. De encryptiemethode draagt geen zorg voor authenticatie noch voor integriteit. Jij kan het bericht nu wel ontcijferen, maar je weet niet van wie het afkomt, noch of de inhoud van het bericht wel is wat er verstuurd werd. Misschien is er namelijk nog wel een derde persoon die de sleutel ook heeft, en heeft die het bericht tussendoor aangepast! (Noot: met moderne ciphers werkt dat zo niet meer natuurlijk, maar dit is puur even als voorbeeld.)
Eechter: een ieder die de sleutel niet heeft, kan het niet lezen. Wat dat betreft heb je dus wel vertrouwelijkheid!
Bonus link:
http://blog.atmel.com/201...ption-and-authentication/
Enkel integriteit = Geen garantie met wie je praat en geen garantie dat het versleuteld is, maar wel garantie dat de data die aan jou verstuurd is ook daadwerkelijk de data is die verstuurd moest worden.
Voorbeeld: Een random persoon maakt een stukje software, en publiceert hier een SHA hash van. De software is niet encrypt, iedereen kan het downloaden. Jij kan het downloaden. Je kan nu enkel zien of de software die je binnen hebt gekregen daadwerkelijk de software is die aangeboden werd, maar je hebt geen bewijs wie het gemaakt heeft noch is het stukje code waar de software uit bestaat vertrouwelijk.
-----
HTTPS gebruikt een combinatie van die drie, (authenticatie + encryptie + integriteit) dus niet enkel authenticatie zoals jij wilt beweren: maar zowel authenticatie als encryptie. En daarnaast ook nog eens integriteit van de HTTPS pakketjes zelf.
(Doch niet van de data die je verstuurd binnen die pakketjes!! Dat is ook nog ff een puntje dat opgemerkt moet worden.
)
Authenticated en Integrity los van elkaar zien bij cryptografie is trouwens behoorlijk academisch en zou in de praktijk eigenlijk belachelijk zijn omdat je dan geen werkelijk vertrouwen kan hebben; als je de integriteit niet kan controleren, wat heeft de authenticatie dan nog voor zin? Maar ze zijn wel degelijk los van elkaar te zien en het zijn twee aparte zaken.
In de praktijk komen Authentication + Integrity dus vrijwel altijd bij elkaar.
Maar Authentication + Integrity (controleren wie het verstuurd heeft, en of de inhoud wel klopt) komen absoluut niet altijd samen met encryptie! (zorgen dat niemand het kan lezen.)
En dat is nou het fundamentele probleem waarom ik jou "het garandeert enkel met wie je praat" opmerking onjuist vind.
Het is echt: "het garandeert met wie je praat, en het garandeert dat je enkel met die persoon/server praat en niemand anders het kan lezen.".
HTTPS blijft dus toch echt "de garantie dat je praat met wie je praat, en de garantie dat het verkeer versleuteld is."
Alhoewel daar ook weer een haakje en oogje aan zit: namelijk de integriteitscontrole die hier niet standaard bijzit in alle situaties; maar die enkel van toepassing is op de pakketjes zelf. (Kolere wat een hoop uitzonderingen.
)
Je kan prima verifieren met wie je praat, zonder dat de data zelf encrypt is... Het is jammer dat je net doet alsof die technieken totaal niet bestaan. Dat er iemand tussen gaat zitten, neemt in dat soort gevallen niet weg dat je alsnog praat met wie je wilt praten: immers valt de inhoud totaal niet te manipuleren.
En dus praat je alsnog met wie je wilt praten, en kan je zien dat dat zo is; ongeacht dat er iemand tussen zit of dat meer mensen mee kunnen luisteren/lezen.
Snapje?
Ik bedoel, bij een HTTPS verbinding zitten er ook tig routers tussen; dus eigenlijk is enkel *authenticatie en integriteit* (eg: via signature), en dus niet encryptie!, van belang om te controleren of wat jij binnenkrijgt wel is van de persoon/server met wie jij wilt praten. Het *encryptie* gedeelte is enkel van belang om te zorgen dat anderen het niet kunnen lezen: maar het is *authenticatie* dat ervoor zorgt dat jij zeker weet met wie jij praat.
(En "*direct* praten met" is bij HTTPS dus bijna nooit het geval. Eerder "*enkel* praten met"; dus dat niemand het kan lezen ongeacht wie er allemaal tussen zitten. Kan je mierenneuken vinden, ik vind het een belangrijk nuance verschil...)
HTTPS is wel: garantie dat je praat met met de juiste server, dat de data die uitgewisseld wordt encrypt is en dat de integriteit van de verstuurde pakketjes an sich correct is.
HTTPS is dus niet: enkel garantie dat je praat met de juiste server, maar geen garantie dat de data encrypt is.
Dat laatste is echter wel wat jij steeds zegt.
Mega groot verschil!
Ik hoop dat je dat wel begrijpt nadat je m'n linkjes hebt gelezen en de uitleg hebt gelezen, en derhalve ook snap waarom ik je op dat punt corrigeer. Misschien kan je zelf ook nog eens zoeken naar het verschil tussen authenticatie en encryptie.
HTTPS is echt niet enkel authenticatie zoals jij beweert, maar zowel authenticatie als encryptie. En dan heb je dus ook nog integriteit, maar dat wordt niet per se gegarandeerd door HTTPS zelf bij het uitwisselen van data! Enkel de authenticiteit, integriteit en encryptie van de pakketjes zelf wordt gegarandeerd: maar de *inhoud* van de pakketjes; bijvoorbeeld een e-mail, PDFje of een stuk software, daar wordt de integriteit (authenticiteit ook niet perse, trouwens.) niet van gegarandeerd natuurlijk.
Dat wordt juist
wel weer gegarandeerd door een keyed Digital Signature toe te passen op de data die je verstuurd.
(... of door een andere vorm van integriteitscontrole, zoals via MD5/SHA hashes.) Als je bijvoorbeeld software gaat downloaden, dan gebruik je in de ideale situatie: authenticatie + encryptie + integriteitcontrole. De eerste twee vinden plaats dankzij HTTPS (ben ik wel verbonden met die mirror, en is de verbinding versleuteld?), de laatste controleer je via een hash. (En de pakketjes van HTTPS zelf worden automatisch ook al op integriteit gecontroleerd.)
Echter, bij het inloggen bij de bank kan je er natuurlijk wel vanuit gaan dat de data die je binnenkrijgt ook is wat je bank je heeft gestuurd, je zit immers client-server verbonden en dat is verifieerbaar; dus zou het op de server al aangepast moeten zijn. (Doch: dat is mogelijk...! Maar zeer onwaarschijnlijk. Toch zou een extra signature niet mis zijn voor die data, voor bepaalde accounts en het maken van overboekingen.
)
En die extra authenticate + integrity doe je het liefst natuurlijk ook als je in een client-server-client opzet terecht komt!
(Bijv.: ik verbind via HTTPS met de server, Pietje doet dit ook. Maar het document wat ik naar Pietje via deze verbinding stuur: daar voeg ik een Digital Signature aan toe, zodat Pietje zeker weet dat het van mij is *en* dat de inhoud onderweg niet gewijzigd is door de server!)
Snap je de grote verschillen tussen deze zaken nu?
Bonus link:
https://www.owasp.org/ind...er_Protection_Cheat_SheetMaar, for the sake of discussion, laat ik dan toevoegen "zonder een groot risico te lopen afgeluisterd te worden". Want óók die encryptie is niet waterdicht, en ook SSL-certificaten kunnen vervalst worden.
Dat is niet enkel for the sake of discussion, dat is om je uitspraak accuraat te maken.
Zo klopt het namelijk een stuk beter, met dat zinnetje erbij.
SSL Certificaten vervalsen is trouwens makkelijker gezegd dan gedaan... Zeker zonder toegang tot de netwerken en sleutels. Na de hack bij diginotar bijvoorbeeld was het wel prima mogelijk voor certificaten die door hen uitgegeven waren; daarom werden ze ook linea recta ongeldig verklaard. Over het algemeen kun je er met een zeer hoge mate van zekerheid vanuitgaan dat een SSL certificaat dat een OK status krijgt, ook daadwerkelijk correct is en niet vervalst is.
Maar sure; als je iets echt extreem belangrijks overstuurt: dan moet je er vanuit gaan dat het niet zondermeer veilig is, en extra stappen ondernemen.
Bijvoorbeeld de data apart encrypten van de encryptie van de verbinding zelf...
Mijn uitleg deugt, jouw interpretatie niet. Zo simpel is het.
Neen, je uitleg was onjuist. Punt.
Het is, buiten jouw belevingswereld om, namelijk nogal eens de gewoonte dat mensen denken dat een bepaalde website https gebruikt, 'dus' zal het veilig en betrouwbaar zijn.
En daar kun je over het algmeen ook prima vanuit gaan, tenzij je op shady websites komt.
Als je bijvoorbeeld bij je bank inlogt, bij PayPal, hier op Tweakers of waar dan ook wat respectable sites zijn: dan kan je er prima vanuit gaan dat de verbinding veilig en betrouwbaar is, en dat de ontvangende partij geen misbruik zal maken van de door jou verstuurde data. Dat geeft wel zo'n veilig gevoel!
Het is tegenwoordig ook redelijk de uitzondering dat de beter bezochte websites de wachtwoorden niet perfect encrypten, in plaats van plain-text op te slaan.
Ja, je kan heel paranoide gaan zitten doen; maar zet dan gewoon je PC uit.
Veiligheid staat boven alles, laat dat voorop staan: maar er moet ook nog een stukje usability en vertrouwen zijn. En als jij gewoon sites met een goed aanzien bezoekt, dan kun je er prima vanuit gaan dat SSL de data die je verstuurt beveiligd; en dat de website/dienst die je gebruikt jou wachtwoord veilig opslaat en bewaart.
Echter, de ontvangende partij kan natuurlijk gehacked worden. Hier op Tweakers bijvoorbeeld zou de database gejat kunnen worden, hoe betrouwbaar de staff hier ook is. (En ik acht ze zeer betrouwbaar... Heb ze nu een paar keer mogen ontmoeten, en er zijn niet veel mensen met zulke diepe kennis en een gevoel voor veiligheid en privacy waarboring.) Daarom is het ook van levensbelang om bijvoorbeeld niet aan "password recycling" te doen, of de wachtwoorden nou gehashed worden of niet. Dat is echter richting offtopic, dus daar zal ik verder niet al te diep op ingaan.
Het misbruiken van data bij de ontvangende kant, doet echter niets af aan de nuttigheid van SSL.
SSL/TLS is gewoon van levensbelang op internet, it's that simple. Er is niets "overrated" aan.
Maar ja, als je een punt wil maken hier moet je blijkbaar alle randvoorwaarden noemen, anders zijn er blijkbaar mensen die niet helemaal snappen wat je bedoelt. En dat geeft niks; maar om hun onvermogen om iets van de materie te begrijpen gelijk te projecteren op een ander is een tikkeltje.. hoe zeg je dat.. sneu.
Haha, over sneu gesproken... Kan je nou echt geen enkele post maken zonder op de man te gaan spelen?
Nogmaals: doe eens normaal man. Ik val jou ook niet op de man aan omdat je kennelijk nog nooit gehoord had van signature verification. Maar omdat je daar nog nooit van gehoord hebt, vind ik niet dat dit meteen "onvermogen" is... Je hoeft niet alles te weten.
Ik was sarcatisch, maar heb je algehele intellegentie niet in twijfel getrokken. Als je bezig blijft met Ad Hominem aanvallen, zal ik daar denk ik langzaamaan echter wel aan gaan twijfelen.
Je uitleg is gortig en gewoon onjuist als we het over HTTPS hebben. Dat geeft helemaal niets, dat kan gebeuren. Als mensen het "niet snappen", dan moet je misschien even bij jezelf gaan afvragen of je uitleg wel zo goed was.
Er viel niets verkeerd te snappen aan je uitleg: de uitleg zelf was gewoon incorrect.
Daarnaast kan je, mits je vond dat je uitleg goed was, ook gewoon je mening opnieuw onderbouwen zonder hierbij op te man te spelen. Dat je kennelijk niet zonder kan, is een beetje jammer...
Daarnaast zeg je het zelf al, dit is Tweakers; Er komen zowel leken als experts, dus moet er wel de juiste informatie staan met een uitleg die voor iedereen begrijpelijk is. Jij geeft die niet. Beetje hypocriet om dan te gaan klagen als iemand je verbeterd.
Je kan ook gewoon vriendelijk eventjes bedanken voor de verbetering en er iets van leren, you know... Er is helemaal *niets* mis met fouten maken of een techniek verkeerd snappen. In plaats van boos te worden, kan je ook gewoon weer wat opsteken; en dat is dan ook waarom ik op je reageer; en op je blijf reageren om de zaak recht te zetten.
Niet zo boos joh.
* Voorwaarden voor een SSL-certificaat zijn bijvoorbeeld, maar niet beperkt tot, NAW-gegevens en telefonische controles van de echtheid van de domeinnaamhouder door de certficerende instantie(s).
Dat ligt aan het type certificaat.
Het gros van particuliere websites zijn gewoon Domain Validated. Daar komen totaal geen NAW gegevens of telefonische controle aan te pas. Steker nog: daar wordt totaal niet naar gekeken. Het enige dat gecontroleerd wordt, is of jij wel toegang hebt tot de mailbox in de whois gegevens van dat domein; of een van de andere "common mailboxes" binnen dat domein (eg: postmaster, admin, etc.)... De CA weet dan totaal niet wie jij bent, noch wie het aanvraagt. Als ik toegang heb tot de mailbox in jou whois gegevens, of 1 van de common mailboxes binnen jou domein (aldanniet illegaal), dan kan ik prima voor jou een SSL certificaatje aanvragen.
Bij SSL certificaten op basis van Extended Validation (waarbij je zo'n compleet groene balk in je browser bar krijgt) zijn weer een heel ander verhaal, daar moet je een zee aan informatie aanleveren en door allerlei controles heengaan. De veiligheid en verzekering is dan ook sterk verhoogd.
Trouwens, misschien dat je er even een Engels woordenboek op na moet slaan, maar 'overrated' is niet hetzelfde als 'waardeloos'. Overrated, zeker in deze context, betekent dat er onterecht tevéél waarde aan wordt gehecht, precies om de reden die ik aangeef. De techniek is prima. Waar het vaak aan schort is de implementatie en consumenten die blind vertrouwen op dat groene adresbalkje. Ook bij sites die https gebruiken moet je blijven opletten wat er met je data gebeurd, da's alles.
Ik weet wat het betekend, maar ben het gewoon niet met je eens. Er wordt niet klakkeloos teveel waarde aan gehecht, het een maakt het ander niet minder namelijk.
Het laat onverlet dat HTTPS nog altijd geen "overrated" techniek is, maar een extreem belangrijke techniek voor communicatie die over het internet heenvliegt.
Dat je moet opletten of de ontvanger wel netjes met je data omgaat: uiteraard. Maar dat doet niets af aan HTTPS, en dat leg je naar mijn mening totaal niet goed uit; jou eerste post maakte de suggestie dat HTTPS an sich overrated is: en dat is het absoluut
niet.
Ik ben het dus niet met je oneens dat je wel zeker moet zijn dat de ontvanger betrouwbaar is, maar het doet gewoon niets af aan HTTPS zelf.
Derhalve is HTTPS geen overrated techniek. Voor het gros van de mensen die het internet gebruiken, maakt het sowieso weinig uit; maar is het wel van belang dat hun wachtwoord niet in transit achterhaald kan worden.
Mensen versturen hun data ook gewoon in plain-text als er geen SSL is, ook naar shady sites. (Phising, anyone?) Dat klakkeloos versturen en er vanuit gaan dat de site betrouwbaar is, gebeurt dus ook zonder SSL.
Wat dat betreft kan je daar beter eerst aan werken, dan over HTTPS te klagen.
Veel mensen weten niet eens wat HTTPS is of dat het uberhaupt bestaat.
Als jij om die reden HTTPS overrated vindt: so be it, dan zullen we het wat dat betreft helaas wel oneens moeten blijven.
Bottom line: Ja, je moet altijd opletten aan wie je je data verstuurt; en of die wel te vertrouwen is/zijn. Neen, dat maakt HTTPS niet overrated of een gevaar vanwege "schijnveiligheid".
[Reactie gewijzigd door WhatsappHack op 22 juli 2024 22:39]
De http strict transport-bescherming is naar IE 11 op Windows 7 en 8.1 gekomen als onderdeel van cumulatieve beveiligingsupdates die op patch-dinsdag werden uitgerold, meldt Microsoft. Hsts was al aanwezig in Internet Explorer 11 in de Windows 10-preview en ook de nieuwe Edge-browser bevat de feature.
:strip_exif()/i/1315901421.gif?f=fpa)
:strip_exif()/i/1297080812.gif?f=fpa)
/i/1316504693.png?f=fpa)
:strip_icc():strip_exif()/u/25867/no_bugs_small.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/79614/Family-Guy-Victory-is-Ours.jpg?f=community){kind=small}
/u/49730/babby%2520tux.png?f=community){kind=small}
:strip_icc():strip_exif()/u/216736/profile.jpg?f=community){kind=small}
/u/407403/WAhack.png?f=community){kind=small}
:strip_exif()/u/677/crop5e62ccc026e5a_cropped.gif?f=community){kind=small}
). :strip_icc():strip_exif()/u/57655/SuperTeamLogo.jpg?f=community){kind=small}
