Google wil http in alle browsers als onveilig markeren

Het Chrome Security Team van Google wil dat alle internetbrowsers een waarschuwing laten zien wanneer iemand een site bezoekt via het 'onveilige' http. Op die manier wil de internetreus bewustwording creëren bij gebruikers wereldwijd.

Vooralsnog gaat het om een voorstel en zou iedereen er er nog zijn zegje over moeten kunnen doen, vindt het team. Desalniettemin meent het Chrome Security Team dat het tonen van een waarschuwing bij een onbeveiligde verbinding de veiligheid van internetgebruikers ten goede komt, omdat die dan geïnformeerd kunnen beslissen om door te gaan via http.

Het securityteam van Google denkt dat er drie beveiligingsniveaus voor sites zijn die browsers kunnen onderscheiden. Onder het eerste niveau vallen sites die helemaal via https worden aangeboden. Het tweede is 'dubieus', omdat een geldig ssl-certificaat bijvoorbeeld tls-fouten bevat. Ten slotte is er het onveilige niveau, waarbij een site volledig via http wordt geserveerd of er juist een ongeldig certificaat is.

Door de drie niveaus in een browser te tonen, mogelijk door een bepaalde kleur in de navigatiebalk, kunnen gebruikers beter over de veiligheid worden ingelicht. "De enige situatie waarin webbrowsers nu gebruikers gegarandeerd niet waarschuwen, is precies wanneer ze geen enkele kans op veiligheid hebben, namelijk wanneer de site via http wordt aangeboden", aldus het Chrome Security Team.

Googles team zegt voor volgend jaar met een plan te beginnen om een dergelijke functionaliteit uit te rollen in zijn browser, Chrome. Daarnaast moedigt het team andere browserbouwers aan mee te denken en uiteindelijk met een soortgelijke oplossing te komen.

Reacties (246)

[GeorgeDrake1982]

Met alle (ernstige) beveiligingslekken en afluisterschandalen in 2014 sta ik zeker wel achter dit beleid.

[mcDavid]

Noem eens een beveiligingslek wat gebruik maakte van een MITM aanval? Waar we in het nieuws over horen zijn meestal database- of webserver hacks, daar gaat SSL je helaas niet tegen beschermen.

Ik vind het een beetje een onzinnig voorstel eigenlijk. Heel veel websites met statische content hebben geen enkele baat bij SSL. Als je gebruikers bij iedere site met zo'n waarschuwing om de oren gaat gooien verliest die héél snel zijn waarde, en zal het eerder een averechts gevolg hebben dat gebruikers ook als ze een echt belangrijke waarschuwing krijgen bij het internetbankieren, deze zonder na te denken wegklikken.

[flowerp]

Individuele users zijn wel degelijk slachtoffer geworden van fishing attacks door gewoon (b.v.) WIFI verkeer af te luisteren en te hopen dat mensen iets posten over HTTP.

Dat is in de praktijk helaas meer dan je zou denken.

Fishing praktijk is dan ook laptopje open zetten, tijdje laten scannen en je hebt na een paar uur flink lijstje van username+password+url combo's. Misschien is de URL opzich al leuk om even in te loggen en als je er spam kan achterlaten meteen maar botje ervoor te maken. Ook kun je de username+passwords eens op diverse wat interesantere sites loslaten. Wetende dat mensen gewoonte dieren zijn is er best kans dat er wat leuks tussen zit.

Dergelijke "goedkope truukjes" komen niet heel vaak in het nieuws, omdat het eigenlijk niet zo spannend is. Net zoals een enkele persoon die gerold is niet snel in het nieuws komt, maar een grote kraak weer wel.

Aantal jaar geleden was het wel een keer in het nieuws toen schiphol nog geen eigen WIFI had en daar op relatief grote schaal op werd ingespeeld door eigen access points op te zetten met name als "Schiphol airport WIFI" etc, en die dan te scannen weer.

En je opmerking als "heel veel sites met statische content hebben geen baat bij SSL". Tsja, misschien. Maar moeten we dan b.v. telefoongesprekken (GSM) ook maar gewoon op geen enkele manier beveiligen? Gewoon alla oude portofoon en bakkie direct de ether in gooien zodat iedereen lekker mee kan luisteren? Heel veel gesprekken hebben toch geen enkele baat bij encryptie, toch?

[mcDavid]

Ik ben niet tegen SSL, maar je moet het gebruiken waar het nut heeft. Op inlogpagina's, absoluut. Maar de openingstijden van de supermarkt en het weerbericht van morgen, wil je die echt gaan vertragen met SSL puur omdat het kan? Dat is gewoon onzinnig. En er een beveiligingswaarschuwing bij tonen is minstens net zo onzinnig.

SSL heeft helaas niet alleen maar voordelen, maar ook nadelen. Het heeft een (behoorlijke) performance impact, certificaten kosten geld, moeten beheerd worden en het is niet altijd mogelijk op shared servers. Dat zijn redenen genoeg om in ieder geval niet zomaar klakkeloos het hele internet te encrypten. Een (semi) verplichte beveiligingswaarschuwing zou in mijn ogen net zo irritant en averechts zijn als de verplichte cookiebanners.

[Reactie gewijzigd door mcDavid op 23 juli 2024 01:21]

[tmotd]

Tegenwoordig kunnen caching servers al omgaan met SSL, dus een echte performance issue is het niet. Simpele certificaten (die even goed zijn als duurdere, maar minder 'garantie' bieden) zijn totaal niet duur en zelfs tegenwoordig gratis te krijgen. Als het niet mogelijk is op een shared server zou ik een andere ISP zoeken, want dan weten ze niet waar ze mee bezig zijn ;)!

[freaky]

Ah gratis verkrijgbare certificaten. Doe er even een lijstje bij van alle clients die die niet accepteren. Oh wacht, doe maar een lijstje die ze wel accepteren - die is aanzienlijk korter namelijk.

En als jij certificaten wil op onze shared hosting kan dat hoor. Maar niet huilen dat je niet de default vhost bent voor SSL en dat je bezoekers die geen SNI ondersteunende client hebben komen klagen dat ze een certificaat van een andere website te zien krijgen op jouw site.

Je kan ook bijbetalen voor een dedicated IPv4 adres uiteraard. Zolang die nog beschikbaar zijn tenminste. Als dit doorgevoerd wordt kun je verwachten dat de prijzen voor die IP adressen binnen afzienbare tijd ook aanzienlijk gaan stijgen, gezien het tempo waarin ze op raken ook aanzienlijk toe zal nemen.

[xleeuwx]

Srry maar om vandaag de dag nog over SNI te beginnen terwijl bijna alle browsers dit al ondersteunen en anders had je al af moeten vragen of je uberhoud al websites moet bezoeken met die pc:

Internet Explorer 7 or later, on Windows Vista or higher. Not in any Internet Explorer version on Windows XP because SNI depends upon the SChannel system component shipped with Windows Vista.[7]

bron

[Reactie gewijzigd door xleeuwx op 23 juli 2024 01:21]

[freaky]

Je kunt als IT'er prima de moraal ridder uithangen, maar als het 5-10% van de omzet kost komen ze van uit management/verkoop je toch je nek omdraaien ben ik bang .

Neemt niet weg dat je wel gelijk hebt dat het verouderd is.

Er is overigens meer dan Windows en IE. Je vergeet voor het gemak alle mobile devices maar bijv. En daar zijn er redelijk wat bij waar de fabrikant niet al te scheutig met updates is.

[tmotd]

Hoe jij 5-10% omzet wil persen uit mensen die zelfs geen geld uitgeven om hun systeem een beetje up-to-date te houden ontgaat mij. Zei hebben namelijk wel grotere problemen dan dat de website niet werkt (beveiliging).

[freaky]

15% draait nog ie8 en 21% andere niet recente versies (wereldwijd overigens). Een aardig deel daarvan zal geen SNI doen.

Hoeveel omzet het scheelt ligt uiteraard aan het publiek. Als je game PC's verkoopt zal het niet veel uitmaken. Bij Wehkamp of Otto oid zal het aanzienlijk meer schelen gezien het andere publiek.

Dat mensen geen geld uit willen geven aan een PC wil niet zeggen dat ze geen geld hebben. Niet voor allemaal in ieder geval. Mijn stucadoor bijv. draait nog XP, hij typt 2 briefjes per dag, bekijkt wellicht enkele voor hem bekende websites (hij shopt niet of nauwelijks voor betere prijzen), doet wat met email en dat was het wel. Hij vervangt hem wel als dat voor hem nodig is, zij het door hardware problemen of omdat dingen die hij wil doen er niet meer op kunnen. Hij heeft liever een grotere jacuzzi in de achtertuin. Als hij het eenmaal nodig vind kijkt ie niet op een paar centen echter.

Redenaties van dat soort mensen zijn vrij simpel hoor. IT'ers/tech savvy willen vaak wel het laatste, maar trek dat eens door. Moet je ieder jaar een nieuwe auto, fiets, wasmachine en ga zo maar door. Voor hun is een computer gewoon het zoveelste apparaat.

Stellen dat ze allemaal arm zijn is aanzienlijk te kort door de bocht. Natuurlijk zijn die wel onderdeel van dat segment maar ken ook arme mensen die hun computer of auto wel extreem belangrijk vinden en er meer geld aan uitgeven dan financieel gezond is voor ze. Anderen boeit die computer geheel niet, zolang ie doet wat ze willen.

@xleeuwx over wat voor marktsegment heb je het dan?

[xleeuwx]

Bij ons is het 0,3% van de omzet . dus daar ligt niemand wakker van.

[tmotd]

Ik zei alleen maar dat er ook al mogelijkheden zijn om gratis certificaten aan te vragen. In mijn browsers doen die het overigens prima.

Bij mobile devices met SNI moet je denken aan dit lijstje. Dit is dus ook een slecht argument, dat het een +2 informatief krijgt ontgaat mij een beetje daardoor.

Shared hosting met NAT heeft natuurlijk nog wel meer problemen dan SSL certificaten of begrijp ik je nu verkeerd, met wat je bedoeld aangaande vast IP-adres.

[makafeli]

Als je in dit geval een beetje bij blijft in de wereld van SSL certificaten en cipher suites etc. dan weet je ook dat er op korte termijn ECC (ECSDA cipher suite) globaal ingezet gaat worden. De performance tussen SHA en ECC certificaten is aanzienlijk zodat zelfs mobiele gebruikers geen last heeft van performance verlies.

Momenteel heeft Symantec en Comodo certificaten met ECC ondersteuning, echter is het probleem met ECC dat IE het slecht ondersteund, hiervoor zou je kunnen uitwijken naar de Entrust hybrid oplossing wat "the best of both world" aanbied.

SSL certificaten kost geld als je dat wilt, maar je kan ook uitwijken naar
https://www.startssl.com/?app=1 ( de Domein gevalideerde variant is gratis)
en de opkomende Let encrypt is ook een gratis dienst.

Voor shared server is ondertussen ook al SNI (Server Name Indication), dus dat kan je ook afvangen, dus al je argumenten worden ontkracht.

Echter ben ik van mening dat TLS niet overal verplicht moet worden, een website wat alleen informatie verstrekt en geen informatie opvraagt aan de gebruiker zie ik niet zo de added value van...

[geertdo]

Het heeft ook nut op pagina's anders dan inlogpagina's. Ik denk wel dat je gelijk hebt t.a.v. supermarkt websites, alhoewel...

Het gaat om de inhoud van de pagina's. Met HTTPS in combinatie met DNSSEC heb je de hoogste garantie dat de inhoud van de correcte server afkomstig is. Heb je dat niet, dan is er een kans (vooral open WiFi) dat de getoonde inhoud onjuist is.

Stel dat een supermarkt open wifi aanbiedt en je staat in de winkel, hebt verbinding gemaakt en je wilt prijzen vergelijken met de concurrent. Je hebt geen garantie dat deze supermarkt hogere prijzen toont dan de werkelijkheid.
Ik zeg niet dat het gebeurt, maar technisch is het met HTTP zeer eenvoudig.

Natuurlijk zijn er nadelen, maar wegen die nog op tegen de voordelen?

[Jace / TBL]

SSL heeft helaas niet alleen maar voordelen, maar ook nadelen. Het heeft een (behoorlijke) performance impact,

Die impact echt utter peanuts tegenwoordig, kost geen drol meer.

certificaten kosten geld

Je hebt ze al voor 3 of 4 euro per jaar (en dan geen rotte tweederangs shit, op ssls.com bijvoorbeeld gewoon prima erkende valide certificaten van Comodo).
Oftewel totaal insignificant t.o.v. de hosting zelf.

moeten beheerd worden

Eenmalig instellen

en het is niet altijd mogelijk op shared servers.

SNI is al meer dan 10 jaar oud toch

Dat zijn redenen genoeg om in ieder geval niet zomaar klakkeloos het hele internet te encrypten

Kwestie van prioriteiten, maar gezien de massale privacyschending en afluisterschandalen (waarvan nog maar het topje van de ijsberg aan het licht is gekomen) zou ik het absoluut prefereren als 100% encrypted is.

Mensen gaan veel te laks met hun gegevens om. En ook van dingen die nu onbelangrijk lijken weet je niet of je het later liever niet had laten lekken, maar dan is het het te laat. Better safe than sorry.

[GoT]

Performance is tegenwoordig al geen argument meer met een moderne CPU.
Alle (moderne) CPU's hebben tegenwoordig al extra instructiesets ingebakken voor encryptie/decryptie.

Als je bepaalde pagina's wel SSL en bepaalde pagina's geen SSL wilt hebben, dien je dat in te bouwen per pagina. Het is dan makkelijker om de gehele website maar te versleutelen. Error 403 => redirect naar https:// dat stel je in op hoogste niveau website en je hoeft niet meer te rommelen per pagina wat alleen maar extra tijd kost.

[flowerp]

wil je die echt gaan vertragen met SSL puur omdat het kan? Dat is gewoon onzinni

Maar serieus, wil je dan ook dat GSM standaard niet beveiligd is en dat alleen als je een "gevoelig" telefoontje pleegt je expliciet beveiliging moet inschakelen?

Al die standaard beveiliging voor gewoon telefoneren is toch ook onzinnig? En zelfs voor een gevoelig telefoontje is beveiliging misschien voor het grootste gedeelte van het gesprek onzinnig. Misschien moet je het alleen op dat moment aanschakelen dat je iets zegt dat niemand anders mag horen? Want al dat beveiligingsgedoe vertraagt alleen maar toch?

[Nystran]

Heel veel gesprekken hebben toch geen enkele baat bij encryptie, toch?

Deze vergelijking gaat een beetje mank. Volgens mij bedoelt McDavid dat je de krant, ikea catalogus, wijkbrief en reclamefolders niet hoeft te encrypten, omdat dit algemeen bekende data is (al kan het wel interessant zijn dat juist jij deze leest).

Ik snap dat security experts bij Google de stap willen maken naar een https only wereld, maar dit heeft een aantal nadelen.
1. Certificaten aanvragen is ingewikkeld en duur: Op mijn werk (klein bedrijf) zijn wij druk met de migratie naar andere urls en hosting providers, en de certificaten hiervoor goedkrijgen is een secuur en ingewikkeld werkje voor niet experts (laat staan niet-techneuten). Er zijn plannen om dit simpler te maken, en dit is zeker nodig als straks ook alle MKB en hobby-sites en https nodig hebben. Iemand inhuren of aan laten klooien om een certificaat te installeren brengt toch een hoop kosten met zich mee.
2. McDavid noemde het al: vooral in de beginfase: vals alarm. Als je op nu.nl een rode waarschuwingsbalk krijgt, schrik je ook bij abn.nl niet meer van deze melding.
3. Performance: Voor onze desktops niet echt een probleem, maar ik denk dat mobiele providers reikhalzend uitkijken naar https-only: dat zijn een boel extra MB's die ze af kunnen rekenen. En in delen van de wereld zonder breedband kan dit ook een verschil in performance geven.

Edit: blijkbaar zijn certificaten een factor 10 goedkoper dan ik dacht

[Tweekzor]

Je vergeet ook nog, misschien wel de belangrijkste, het feit dat je een uniek IP-adres nodig hebt voor een certificaat. Zolang de wereld nog niet op IPv6 zit is dit onmogelijk

[hackerhater]

Dit is als je win XP negeert allang niet meer nodig.

[Tweekzor]

Oh? Toen ik mijn website op https over wou zetten moest ik toch echt eerst een eigen IP aanschaffen voordat ik een certificaat kon krijgen. Ik weet niet meer precies waarom dit nodig was, het is inmiddels alweer een tijdje geleden maar dat staat me nog wel bij.

[Verwijderd]

In een notendop:
Nagenoeg elke webserver heeft tegenwoordig SNI. SNI zorgt ervoor dat je webserver SSL kan aanbieden op domeinnaam ipv ipadres.

Win XP kan niet overweg met SNI. Alles wat nieuwer is wel.

Afhankelijk van de hoeveelheid WinXP bezoekers je nog hebt kan je dus besluiten om wel of geen extra IP te doen.

http://www.networking4all...n/server+name+indication/

[flowerp]

Volgens mij bedoelt McDavid dat je de krant, ikea catalogus, wijkbrief en reclamefolders niet hoeft te encrypten, omdat dit algemeen bekende data is (al kan het wel interessant zijn dat juist jij deze leest).

Die reclame folders op zich misschien niet, maar is het nodig dat iedereen weet dat ik in de Ikea catalogus 30 minuten door de bedden sectie heb gebladerd, en dat ik bijzonder lang keek naar een 2 persoons bed?

Want dat is namelijk het equivalent van een statische site bezoeken en het verkeer intercepten. Niet alleen de data (die publiek is) is bekend, maar ook dat IK (of in ieder geval mijn IP) naar pagina X, Y, en Z heb gekeken en dat ik op A, B en C heb geclickt.

Dit lijkt misschien een stuk minder spannend dan direct credentials uitlezen, maar ook dit kan vervelende gevolgen hebben als deze data in de verkeerde handen valt.

[geertdo]

WiFi afluisteren door een laptopje met access point is inderdaad een goedkoop trucje. Het is daarom bijzonder jammer dat DNSSEC nog steeds niet beter wordt doorgevoerd.

Zelfs Tweakers.net ondersteunt nog steeds geen DNSSEC

Je hebt met DNSSEC een manier om te zorgen dat je niet naar een dummy site/proxy wordt geleid via DNS spoofing. Ik vind het onvoorstelbaar dat hierin niet meer geïnvesteerd wordt. Je wilt als website eigenaar toch garanties hebben dat een browser dat jouw domeinnaam gebruikt, met de juiste server communiceert?!

[totaalgeenhard]

DNSSEC is ook een magic woord.... klinkt stoer en veilig.

Als je verkeer gespoofed kan worden dus in theorie je resolver voor de gek gehouden kan kan worden dan helpt DNS SEC je ook niet en heb je een veel groter probleem.....

Het is wederom een valse gevoel van veiligheid.

[geertdo]

Advies, verdiep je eens in DNSSEC a.u.b. dan zal je zien dat de MITM het dns verkeer niet kan beïnvloeden.

Erg dom om deze hele goede stap in het verbeteren van veiligheid op internet af te doen met 'vals gevoel van veiligheid'. Kennelijk is er nog iemand die het niet begrijpt, gezien je +2

Vertel maar even hoe je bij DNSSEC de name resolving voor de gek kan houden. Als DNSSEC een stoer en magisch woord is, waarom zijn er dan al meer dan 2 miljoen .NL domeinnamen die het ondersteunen? Denk je nou echt dat die investering wordt gedaan als het toch maar 'een vals gevoel van veiligheid' oplevert? OMG

[totaalgeenhard]

Als eigenaar van een paar bedrijven die meer dan 50.000 sites hosts heb ik weleens gekeken naar DNSSEC...... in de zomer van 1999 om precies te zijn op Chaos Computer Club bijeenkomst in Berlijn, waar ook enkele betrokkenen bij protocol en opensource code rondliepen en lezingen verzorgden.

Heb jij je er weleens in verdiept? Want er is geen OS die standaard een resolver heeft die DNSSEC ondersteund....

Verder als je DNNSEC je "redding" moet zijn, heb je een heel ander probleem, immers men kan dan al bij je verkeerstroom komen en veranderen, derhalve ook hele keten aanpassen.

Op dit moment heb je alleen wat aan DNSSEC als je Chrome gebruikt, wat niet iedereen doet...

Je geeft aan dat er al 2 miljoen zijn..... en dat moet een bewijs zijn voor iets.

Op privé feestjes van SIDN waarbij alleen de grootste registrars worden uitgenodigd worden informeel dingen "bekokstoofd".

SIDN en grootste registrars willen af van al die kleine partijen en in de afgelopen paar jaar (sinds prijs discriminatie van SIDN) is zijn er al een kwart minder registrars.

één van de dingen die er ooit eens op dergelijke feestjes is besproken is invoering van DNSSEC niet zozeer uit security oogpunt, maar om transfer van domeinen lastiger te maken voor leken. Als grote partijen hun hele portfolio van DNSSEC voorzien en een onwetende gebruiker (en gebeurde buiten hun instemming en opdracht om namelijk) gaat domeinnaam verhuizen en nieuwe partij houd er geen rekening mee is domeinnaam voor bepaalde tijd niet zichtbaar, totdat nieuwe registrar dat door heeft en keys wist etc... klant zal natuurlijk niet accepteren dat zijn site na transfer naar nieuwe partij offline is en nieuwe provider daarop aanspreken die niets meer of minder kan verklaren dat het niet hun schuld is...... Grote partijen hebben er belang bij om kleine partijen in een kwaaddagllicht te stellen en op kosten te jagen.

Bovendien gaf SIDN kortingen op domeinnaam registraties die van DNSSEC zijn voorzien (wat ook op dat feestje besproken is) waarbij grote partijen hun hele portfolio hebben omgezet en daarbij duizenden euro's hebben "bespaard" wat door overige partijen is opgehoest.
Naast de kwantiteit korting die grote partijen al krijgen is dat markt corruptie en is het vreemd dat NMA en overheid niet heeft ingegrepen.

SIDN zou pas weer geloofwaardig zijn indien ze van stichting (die veel geld binnen harkt...) zou omvormen naar een vereniging waarbij de registrars de leden zijn en elk jaar bestuur in functie gekozen zou worden.

Aan jouw schrijven te merken, moet ik concluderen dat de SIDN marketing zeer goed is aangeslagen, ik kom zelden kritische kanttekeningen tegen, behalve bij andere kleine ISP's die registrar zijn.

Als keten tussen resolver en root nameserver water dicht zou (kunnen) zijn dan had je ook geen DNSSEC nodig gehad, maar DNSSEC op zichzelf lost dat probleem ook niet op en zolang alle OS'sen niet standaard DNSSEC ondersteunen is het verkeerd om iets te marketten waarvan je weet dat het niet werkt en als het gaat werken het niet het eigenlijk probleem (te resolven hostname naar IP) zal wegnemen.

Hoe weet jij zeker dat als jij iets correct geresolved hebt, dat als jij naar dat IP adres toesurft ook daadwerkelijk bij dat IP zal uitkomen... (HTTPS met EV-certificaat zie mijn mening daarover )

ps: wanneer heb jij voor het laatst in je hosts file gekeken of daar niets vreemds in stond ?

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 01:21]

[Tweekzor]

En je opmerking als "heel veel sites met statische content hebben geen baat bij SSL". Tsja, misschien. Maar moeten we dan b.v. telefoongesprekken (GSM) ook maar gewoon op geen enkele manier beveiligen? Gewoon alla oude portofoon en bakkie direct de ether in gooien zodat iedereen lekker mee kan luisteren? Heel veel gesprekken hebben toch geen enkele baat bij encryptie, toch?

Sorry maar dit is echt totale onzin. Een telefoongesprek is 1-op-1 unieke communicatie die bovendien niet statisch en niet openbaar is. Een website waar alleen informatie wordt weergegeven en bovendien publiek te bezoeken is haalt echt geen voordeel uit SSL. Want ook met SSL kan de url gewoon worden uitgelezen via een mitm en dan kan de aanvaller de website oproepen om alsnog de content op te vragen. Een telefoongesprek is te vergelijken met een chatclient, niet met een website.

[Jace / TBL]

Want ook met SSL kan de url gewoon worden uitgelezen via een mitm

Nope, alleen de domeinnaam (en dan eenmalig, op het moment van de DNS resolve naar het IP), de URL niet.

en dan kan de aanvaller de website oproepen om alsnog de content op te vragen.

Niet ongezien, d.w.z. zonder popups en errors te veroorzaken over kapotte certificaten.

[Tweekzor]

Nope, alleen de domeinnaam (en dan eenmalig, op het moment van de DNS resolve naar het IP), de URL niet.

Klein verschil inderdaad, mijn fout.

Niet ongezien, d.w.z. zonder popups en errors te veroorzaken over kapotte certificaten.

Daarmee doelde ik op het opvragen van de https website op de computer van de aanvaller op basis van de domeinnaam welke hij afgeluisterd heeft. Hierbij vindt er dus geen interactie plaats met de opgevraagd pagina van het 'slachtoffer' en wordt deze normaal weergegeven.

[flowerp]

Een website waar alleen informatie wordt weergegeven en bovendien publiek te bezoeken is haalt echt geen voordeel uit SSL.

Toch wel, want ook mijn browse geschiedenis is 1-1 gedrag.

Nu is het wel bekend dat ik bij amazon.com ben geweest met een MITM en SSL, maar heb ik daar naar blu-rays gekeken of naar dart pijltjes? Heb ik misschien naar tenten gekeken, of naar huwelijksringen?

Kortom, genoeg dingen die ik ook op statische (uitgelogde) sites net zo min direct wil dat iedereen dat weet dan dat ik mijn vriend opbel en overleg over wat we vanavond gaat eten.

[xleeuwx]

Blijf dromen, als ik een wifi punt opzet en ik zorg dat ik de server ben en een geldig certificaat uitdeel aan de gebruiker zal deze er nooit achter komen dat hij niet met ze bank aan het praten is. Ik hoef alleen voor een beveiligde verbinding te zorgen richting de bank en klaar. Probleem is dat mensen absoluut niet bewust zijn wat ze doen op het internet. En als we dan zon melding gaan krijgen net als dat je een verkeerd SSL certificaat hebt ga je niet lekker meer website's bezoeken.
https://support.cdn.mozil...10-19-09-09-25-5809bb.jpg

[freaky]

en een geldig certificaat uitdeel

Post hier eens een certificaat dat mijn browser vertrouwd voor mijn.ing.nl.

Vind je het erg als ik mijn adem niet in houd in de tussen tijd?

[xleeuwx]

een geldig certificaat hoeft een certificaat van de bank te zijn. Controleer jij elke detail in een certificaat ? elke keer als je inlogt op je bank account ? ook al gebruik ik een geldig certificaat van bijv. mijn.Lng.nl zal niemand het door hebben.

[Reactie gewijzigd door xleeuwx op 23 juli 2024 01:21]

[freaky]

Nee ik gebruik m'n bestaande favoriet koppeling of het autoaanvullen in m'n browser om op die site te komen.

Rest de vraag hoe je mij zo ver krijgt om naar mijn.Lng.nl te gaan, want mijn.ing.nl zal gewoon een hele dikke certificaat wordt niet vertrouwd melding weergeven.

En gezien ik gewoon mijn favorieten gebruik is de kans dat ik die URL verkeerd invoer aanzienlijk klein.

Bovendien hoef ik niet alles te controleren. Gezien mijn.ing.nl een EV heeft staat daar heel dik in groen voor: "ING BANK N.V. [NL]". Nu zal ik die tekst niet altijd lezen, maar als dat groene stuk ontbreekt gaat er al genoeg rinkelen.

[xleeuwx]

Zodra ik een wifi punt opzet (waar dit allemaal om ging), kan ik je DNS aanpassen, vervolgens redirect ik je van (mijn.ing.nl op mijn server waar ook de wifi punt op draait naar mijn website mijn.lng.nl) Vervolgens heb jij een perfecte verbinding beveiligd en wel met mijn server die onderwater gewoon de website van ING opvraagt en vervolgens kan ik gewoon met je meekijken en / of rustig de request aanpassen.

Dat jij niet weet dat het kan betekend niet dat het niet kan / gebeurt.

[freaky]

Als je gelezen had wist je dat ik m'n favorieten gebruik, net als veel mensen. Die zet de initiele connectie meteen met https op.

Redirect zonder cert melding gaat hem niet worden in dat geval. Ongeacht hoeveel DNS je omleid.

Ik zou geen aannames doen over wat ik wel of niet weet overigens.

[Verwijderd]

freaky vooral zo blijven denken, komt wel goed.

[xleeuwx]

Zet ik een proxy op

Geloof mij nou maar dat het mogelijk is, jou favorieten zijn niet heilig, jou verbinding ook niet.

Het punt is jij moet een verbinding maken uit eindelijk moet je naar een server toe. Jij controleert niet of de server IP het zelfde is als de server IP die je normaal gebruikt, en nee ik controleer dat ook niet.

https://www.myhttpsproxy....VAs_/2FgDYdlg/_3D_3D/b29/

[GeorgeDrake1982]

Het certificaat is gekoppeld aan de domeinnaam. Banken hebben een EV certificaat waardoor browsers een groene label of balk tonen. Als je freaky op afstand kunt MITMen, ben je een goud waard als white- én blackhat hacker. Dan feliciteer ik je!

[Jace / TBL]

Zodra ik een wifi punt opzet (waar dit allemaal om ging), kan ik je DNS aanpassen, vervolgens redirect ik je van (mijn.ing.nl op mijn server waar ook de wifi punt op draait

Als jij op jouw server geen geldig certificaat hebt voor mijn.ing.nl (en dat heb je niet) zal een browser er ook niets van accepteren, ook geen redirect.

[flowerp]

Zodra ik een wifi punt opzet (waar dit allemaal om ging), kan ik je DNS aanpassen, vervolgens redirect ik je van (mijn.ing.nl op mijn server waar ook de wifi punt op draait naar mijn website mijn.lng.nl)

Werkt alleen als ik voor de allereerste keer naar de beveiligde site ga, en alleen als die site geen HSTS preloading heeft. Steeds meer belangrijke sites hebben dat.

Dat zijn dus 2 voorwaarden waaraan je moet voldoen.

Voldoe je daar niet aan dat is het vrij duidelijk dat jouw access point niet de site is waar ik heen wel.

Kijk, er zit wel degelijk een vulnarability in het opzetten van de allereerste verbinding en de redirect van http naar https, en ELKE intermediate node op het Internet kan daar in principe misbruik van maken, niet alleen een mobile access point (maar mobile access point zijn wel veel makkelijker door eenvoudige criminelen op te zetten natuurlijk).

Alles SSL is dus niet de eindoplossing, maar WEL weer een stapje in de goede richting. Het is hoe dan ook veiliger dan geen SSL gebruiken.

[Gomez12]

In de praktijk is dit toch ietwat moeilijker dan je waarschijnlijk denkt hoor...

Self-signed geeft meldingen, andere naam geeft meldingen...

Momenteel is er bij banken etc maar 1 groot gat wat geen meldingen geeft : hun http-adres die doorstuurt naar https...

Als iemand https://bank.nl intypt dan heb jij een grote uitdaging om dat na te bootsen, je makkelijkste target zit hem erin dat de meeste bank.nl intypen die naar een http gaat (en die kan je beinvloeden) die je weer doorstuurt naar https.

[EraYaN]

Als ze dit nou doen laat ze het dan alsjeblieft beperken voor als iemand bijvoorbeeld iets verzend. (een non GET request zeg maar, of zelfs voor iedere GET met parameters)
Als een pagina statisch en openbaar is heeft het geen enkel nut om deze te beveiligen met SSL/TLS. Iemand kan immers zelf deze url bezoeken.

[eborn]

Veel sites starten bij de eerste request een sessie. Als je initieel via http verbinding maakt, dan is die sessie 'makkelijk' te onderscheppen. Dit is uiteraard op te lossen door bij het inloggen (of zelfs bij elke request) een nieuw sessie id te genereren. Maar anders ben je alsnog het haasje.

[flowerp]

Inderdaad, voor de kenners, dit is de zogenaamde session fixation vulnarability.

Veel moderne APIs om web apps te bouwen bieden wapenen zich hier inderdaad tegen. In Java EE (Servlet) kun je de session ID programmatisch veranderen vanaf de server, en in Tomcat kan dat zelfs automatisch zodra er is ingelogd. Diverse andere frameworks hebben dezelfde soort functionaliteit.

[EraYaN]

Het is sowieso een goed idee om je sessie cookies bijvoorbeeld secure only te maken. Als je al een sessie nodig hebt is het waarschijnlijk ook wel handig om over https te communiceren al is het alleen maar om de sessie ID.

[flowerp]

Dat ook ja, standaard flags zijn dan ook secure en httpOnly (wat betekent dat scripts ze niet kunnen uitlezen, mocht je toevallig ook nog een XSS hole hebben)

[TVH7]

Wel is het zo dat je ook met HTTPS nog steeds heel simpel kan fishen door middel van het cookie te stelen van de desbetreffende gebruiker.
Maar ik ben zeker voor alhoewel het wel een probleem kan gaan worden voor de simpele kleine bedrijfjes die alleen maar een soort visitekaartje online hebben. Die worden dan allemaal al gelijk als 'potential danger' beschilderd terwijl die hoogstwaarschijnlijk nooit een ssl cert nodig gaan hebben voor wat ze doen.

[Reactie gewijzigd door TVH7 op 23 juli 2024 01:21]

[freaky]

Mja en laten we vooral even vergeten dat er nog legio clients zijn die geen SNI doen en hordes websites naar een eigen IPv4 adres kunnen verkassen hierdoor. Evenals op kosten gejaagd worden voor een certificaat.

[Yggdrasil]

Dat valt wel mee. De enige browser die geen SNI ondersteund en nog een noemenswaardig marktaandeel heeft is IE8 op Windows XP, en dat neemt snel af.

XP wordt nu al niet meer ondersteund. Tegen de tijd dat dit voorstel van Google werkelijkheid kan worden zal het aandeel nog een stuk kleiner zijn. Daarnaast is met IE8 i.c.m. XP genoeg mis dat het mijns inziens geen kwaad kan om mensen te 'motiveren' eindelijk eens iets anders te gebruiken. Het zou mooier zijn als daar een vriendelijkere manier voor was, maar ja.

[edwinjm]

Hoe wil je het cookie stelen als het is geencrypt?

[geertdo]

Bij HTTPS is alleen transport geencrypt. Zonder DNSSEC kun je als MITM de domeinnaam resolving beïnvloeden en een request voor een site naar een 'voorbereide' server leiden. Daar kun je de cookie uitlezen of opeten

[Jace / TBL]

Maar die 'voorbereide' server geeft dan toch geen valide certificaat terug voor dat domein?

Dus zeker als de site in kwestie STS aan heeft staan (wat me onderhand wel gebruikelijk lijkt bij HTTPS sites), kun je dat soort geintjes niet ongezien doen zonder popups en warnings over kapotte certificaten.

[geertdo]

Maar die 'voorbereide' server geeft dan toch geen valide certificaat terug voor dat domein?

Moet dat dan? 9 van de 10 let er niet op.

[Jace / TBL]

Nou ja als je dit te zien krijgt bij het bezoeken van mijn.ing.nl:

[GROOT ROOD KRUIS]

Your connection is not private

Attackers might be trying to steal your information from mijn.ing.nl (for example, passwords, messages, or credit cards).

En je gaat dan nog je klakkeloos je betaalgegevens invullen, dan verdien je het ook wel een beetje om beroofd te worden.

Het niet kunnen spoofen van een site zonder zo'n vette duidelijke warning te verootzaken, is wat mij betreft toch een aardige drempel, en dat is waar HTTPS o.a. voor zorgt. Dat alleen al lijkt mij reden genoeg om HTTPS te prefereren boven HTTP.

[Deathspike]

HTTPS doet een handshake (en dus de gehele afspraken voor HTTPS encryptie tussen client/server) voordat er HTTP headers over de verbinding gaan. Een cookie is niets meer en niets minder dan een enkele HTTP header, en deze zal bij een HTTPS verbinding ook versleuteld zijn. Het is niet mogelijk om zomaar leuk een cookie te stelen door MiTM op een HTTPS verbinding, in ieder geval niet zonder de encryptie te breken of een trusted root certificate te installeren bij je doelwit (en als je dat kunt is er meer mis dan alleen netwerk beveiliging).

[Noeandee]

Ik denk dat je hier een afweging moet maken tussen wat praktisch is en hoeveel zwaarte beveiliging moet hebben in het dagelijks gebruik van internet door miljarden mensen. Natuurlijk is het zo dat HTTPS verkeer beduidend veiliger is, om als protocol te gebruiken bij het surfen. Ik vrees echter, dat als je HTTPS gaat standaardiseren, zoals Google eigenlijk voorstelt indirect, dat er meerdere vervelende consequenties uit voort kunnen gaan rollen. A ) De huis- tuin en keukenwebsites zullen voortaan certificaten moeten gaan aanschaffen, wat geld kost. Dus amateur websites zullen iig minder snel bezocht worden, aangezien ze als onveilig worden aangeduid of zullen misschien helemaal niet online gebracht worden, omdat het geld kost. B ) Veel mensen zullen inderdaad de neiging hebben deze waarschuwing te gaan normaliseren. Na 50 keer zo'n waarschuwing gehad te hebben, zal men de meldingen uitzetten of niet meer zien.

Aan de andere kant is er al een soort waarschuwing in de vorm van het 'slotje' in je site-veld. Wat aangeeft of een website een geldig certificaat heeft of niet. Dit is in principe hetzelfde lijkt me, alleen dan nog meer in het oog springend.

[Reactie gewijzigd door Noeandee op 23 juli 2024 01:21]

[davekok]

Dat was ook mijn eerste reactie. Maar als ik het artikel goed interpreteer gaat het ze niet zozeer om een melding maar meer om een visuele hint. Zoals de kleur van de adresbalk, net zoals bij https. Daar kan ik niet zo mee zitten. Voor een IT'ers is het voldoende om http in de adresbalk te zien, dan weet je genoeg. Maar nu dat het gebruikelijk is geworden om http uit de adresbalk te laten. Kan het wel handig zijn.

[Pikoe]

Met https ben je er ook niet meteen, als ik de tests van https://www.ssllabs.com/ssltest/ mag geloven zijn er genoeg sites die wel https hebben, maar features hebben ingeschakeld die het gebruik helemaal niet veilig maken.
Ook vrij belangrijke sites als bijvoorbeeld de webmail van de eerste en tweede kamer in nederland, de webmail van de publieke omroep of het intranet van het europarlement.

En als je ze er een mail over stuurt krijg je geen reactie, dus ze vinden het of de normaalste zaak van de wereld, of ze lezen hun mailtjes niet.

[Reactie gewijzigd door Pikoe op 23 juli 2024 01:21]

[Armin]

beveiligingslekken en afluisterschandalen in 2014 sta ik zeker wel achter dit beleid.

Boy Cry Wolf ...

Als ik tweakers.net leest en niet ingelogd ben is er niets 'onveiligs' aan HTTP tov HTTPS. Wellicht dat het MITM drive-by malware lastiger maakt, maar dat is wel heel exotisch.

Google wil nu verder ook verschillende gradaties maken of je een SHA1 of SHA2 certifciaat hebt, en ook afhankelijk van de verloopdatum. Als je dan een SHA1 EV certificaat hebt waar de EV verifciatie slaagt krijg je dezelfde 'score' als een SHA2 certificaat waar de EV verificatie faalt. Dat laatste echter vind ik bijvoorbeeld significant belangrijker.

Het wordt te complex voor de gewone gebruiker, en daarmee wordt de zaak juist onveiliger. Immers het gaat nu regelmatig voorkomen dat doodgewone sites 'onveilig' worden bestempeld, dat mensen bij sites waar écht iets mis is, dat wellicht gaan negeren.

[GeorgeDrake1982]

Encryptie is niet alleen voor veiligheid maar ook authenticiteit van de server en echtheid van de data. Een HTTP-verbinding biedt dat niet.

[Reactie gewijzigd door GeorgeDrake1982 op 23 juli 2024 01:21]

[Armin]

Klopt, maar daarom zei ik dus ook al:

• Als ik tweakers.net leest en niet ingelogd ben is er niets 'onveiligs' aan HTTP tov HTTPS. Wellicht dat het MITM drive-by malware lastiger maakt, maar dat is wel heel exotisch.

Ik ben een groot voorstander van HTTPS, maar ik ben ook een groot voorstander van duidelijkheid. Door volledig 100% veilige HTTP-verbindingen als "onveilig" te betitelen, ga je krijgen dat mensen écht onveilige situaties gaan negeren omdat de melding 'gewoon' wordt.

Precies zoals in het "Boy Cry Wolf" sprookje ...

[GeorgeDrake1982]

Ligt eraan wat jij "veilig" beschouwt. Als informatie tampered aankomt en dus andere content/adviezen opgevolgd worden door de lezer, dan kun je dat ook zien als "onveilig".

[velenski]

ik ben zwaar tegen, want als eigenaar van een hosting bedrijf, kleine website eigenaren kunnen geen certificaat veroorloven vaak.
Dan worden wij als hosters op kosten gejaagd, prijzen zullen stijgen.
Vooral met seedboxen is het een probleem, want dan zouden we overal selfsigned moeten gebruiken, en veel gebruikers schrikken dan van de meldingen die je krijgt.

gaat veel problemen opleveren

[kodak]

Kleine websiteeigenaren kunnen vaak geen certificaat veroorloven?

Die zijn al vanaf gratis of EUR 30 per jaar beschikbaar. Bedoel je eigenlijk niet dat de meeste eigenaren liever goedkope hosting afnemen en veel hostingbedrijven daar hun geld mee verdienen? Want ja, beveiligen kost geld en dan verlies je dus als hoster klanten. Tenzij je in de eerste plaats al niet van die achterlijke prijzen gaat rekenen om een website via https te hosten.

Het negeren van beveiliging, dat is wat de meeste problemen oplevert.

[ongewoongewoon]

Kosten voor het certificaat + extra kosten voor ssl geschikte hosting is toch al snel een meerprijs van 50 euro per jaar.

Beetje onzin voor......een statische website over een hamster.

[Verwijderd]

En dan heb je voor € 50,00 nog geen webhosting inderdaad, daarom zie ik de kleine (zelfstandige) ondernemer ook juist een mafkees van 3 deuren verderop met Linux stoeien op een goedkoop Dedicated Servertje (Atom) van € 4,99 excl. BTW.

Eigen Dedicated IPv4 en IPv6 adres, servertje hooguit ingericht voor de webshop en een gratis (StartSSL) of spotgoedkope SSL Certificaat van een toko als Versio, Enom.com etc.

Gemiddelde prijzen voor webhosting met SSL liggen vele malen hoger en dus is het voor de kleine (zelfstandige) ondernemer steeds interessanter om zo'n goedkoop servertje te pakken. Dat het minder goed beveiligd zou kunnen zijn is tot daar aan toe, maar daar waar het goedkoop kan gaat men er ook veelal voor.

[velenski]

mij gaat het vooral om seedboxen, maar ssl is duurder dan je denkt ivm ip kosten
als ik voor elke seedbox een ssl cert moet hebben, kan dit niet meer uit want een seedbox verkoop je tussen de 5 en tien euro

[_JGC_]

SSL certificaat van een vertrouwde CA kost je een tientje per jaar. Waar de kosten vooral in zitten is de beperking van 1 IP per website. Is wel omheen te werken met SNI, maar lang niet alles ondersteunt dat.

[eborn]

Veel hosters bieden het tegenwoordig allebei aan: SNI voor mensen die geen XP en Android 2.x ondersteuning nodig hebben. En dedicated ip's voor de rest.

[--Andre--]

Als ze dit gaan doen moeten ze gratis certificaten van bijvoorbeeld CAcert gewoon gaan accepteren.

[CAPSLOCK2000]

Google is ook deel van een project om gratis SSL-certificaten beschikbaar te stellen aan iedereen. Toeval of niet, de richting waar Google heen wil is duidelijk: alles encrypten. Ik ben voor. Veilig hoort de default te zijn, niet iets dat je aan het technisch inzicht van de gemiddelde website-eigenaar wil overlaten.

[Bennie98]

Meh, kheb al gemerkt in firefox dat sommige sites niet weergegeven worden vanwege een certificaatfout, terwijl de sites normaal gewoon werkbaar zijn. Kan mij niet schelen of een certificaat goed of fout is zolang ik maar de info van de website kan halen. (heb het hier niet over dubieuze websites maar over standaard websites die mss net een onderhoud hebben of iets dergelijks)

[Verwijderd]

I.d.d. zelfs deze site krijgt regelmatig een melding dat het certificaat niet deugt. Dit soort veiligheid lijkt op de cookie onzin.

[kozue]

Dan begrijp je niet waar certificaten voor zijn. Ze zijn bedoeld om de echtheid van de website te controleren. Als het certificaat niet klopt heb je dus een redelijke kans dat de website fake is (of dat de website nooit is geconfigureerd voor ssl, maar dan had je al niets op de https versie te zoeken).
Als de site ook bereikbaar is via http, betekend dat ofwel dat de content niet belangrijk genoeg is om encryptie te forceren, ofwel dat de makers geen zak geven om jouw veiligheid. In het eerste geval, gebruik zeker lekker de http versie, daar is ie voor bedoeld, maar in het tweede geval zou ik er nooit gegevens op invullen. Als ze hun website al niet op orde hebben zal de rest van hun systemen ook wel zo lek zijn als een mandje en kun je er vanuit gaan dat alle gegevens die je invult door hackers misbruikt gaan worden.

[Bennie98]

ik had het dan ook niet over top secret websites.
Ik had het gewoon over het feit dat ik er dan niet op kan omdat firefox automatisch de https versie wil laden, terwijl ik daar dan zelf op dat moment geen nood aan heb. Mede omdat het geen top secret/login website is maar eerder gewoon info zoals een homemade website waar mss nuttige info op staat voor mij.

[biteMark]

Https is allemaal heel leuk en aardig, maar voor veel websites niet nodig (denk bijvoorbeeld aan de website van de plaatselijke oud ijzer boer) en een ssl certificaat is niet gratis! Je kan niet zomaar klakkeloos alle niet-ssl verbindingen als onveilig markeren, omdat beveiliging niet altijd even belangrijk is en de websitehouder hier weer de dupe van is

[SuperDre]

Alleen zo jammer dat het dan niets meer is dan nep veiligheid, zeker omdat https ook helemaal niet meer veilig is...

[DigitalExorcist]

Onzinnig. HTTPS is schijnveiligheid.

Wat doet https? Het zorgt ervoor dat je verbinding versleuteld wordt. Het is dus erg lastig om je verbinding 'te tappen', tenzij je beschikt over de sleutel of deze kunt kraken. Dat pleit voor https.

Https garandeert dat je praat met wie jij denkt te praten. Maar je kunt ook met de duivel hemzelve praten natuurlijk. Dat zegt dus niets over veiligheid.. ik neem aan dat een rechtstreekse VPN-verbinding naar de NSA óók encrypted is, zeg maar.

[Jace / TBL]

De NSA c.q. duivel kan in dit geval niet doen alsof hij mijn.ing.nl of mijn.favorietepronsite.com is, of whatever je ook privé wilt houden. Dus nee, die vlieger gaat niet op. HTTPS zorgt wel degelijk dat je communicatie beperkt blijft tot 1-op-1, en dat er geen derden (zoals de NSA of andere duivels) kunnen meesniffen.

[DigitalExorcist]

@Jace : dat klopt, dat zeg ik ook. HTTPS garandeert dat jij praat met wie jij denkt te praten. Maar als de ING of mijnfavorietepronsite.com slordig met jouw data omgaat, of gaten bevat, of via de achterdeur al je gegevens gewoon naar partij 'x' doorspeelt, helpt HTTPS je helemaal niks.

[i7x]

Deze reactie slaat echt nergens op. Omdat het bedrijf ook iets totaal anders doet, dat in jouw ogen slecht is, is dit initiatief dat ook?

Ik vind het wel oké. Ik denk dat over een jaar of tien sowieso alle grote websites wel standaard een beveiligde verbindig gebruiken. Het snelheidsverlies is dan ook geen groot probleem meer omdat dat wordt gecompenseert door steeds sneller wordende internetverbindingen.

Het probleem met valse certificaten lost Google ook op door hoge eisen te stellen aan de versleuteling. Zwakkere versleuteling gaat Chrome op den duur ook gewoon als onveilig classificeren. Dat plan hebben ze al aangekondigd en het lijkt mij niet meer dan logisch dat FF, IE, Opera en Safari op den duur zullen volgen.

[Reactie gewijzigd door i7x op 23 juli 2024 01:21]

[Verwijderd]

Tien jaar is een hele lange tijd in de IT. Ik denk dat dit veel sneller doorgevoerd zal zijn. Denk maar eens aan hoe het internet er 10 jaar geleden uit zag.

[Verwijderd]

IE6 is eindelijk dood. Hou oud is XP wel niet....

10 jaar is lang in de IT maar legacy is een draak met overgewicht.

Admin-edit:

Opmerkingen over moderaties horen thuis in het Tweakers Moddereter Forum.

[Reactie gewijzigd door Bor op 23 juli 2024 01:21]

[bogy]

alle kleine bedrijfjes / prive personen met een domeinnaam en eigen site zullen in de rode zone eindigen (onveilig)..

want zij zullen waarschijnlijk eindigen bij de voor hun gemakkelijkst te implementeren optie: gebruik maken van het ssl certificaat van de hosting provider waar ze bij zitten... en dan krijg je dus een 'ongeldig certificaat' melding...

de meeste mensen gaan het geld er niet voor over hebben om een ca-verified certificaat te nemen voor een site die enkel als 'visitekaartje' dient en waar ze geen commercie op voeren...
doordat ze nu een 'red label' erbij krijgen zullen veel websites helemaal verdwijnen vrees ik... dit is voor website-bouwers een slag in het gezicht voor de onderkant van de markt.. de rest zal mss klagen dat het weeral duurder wordt..

[Yggdrasil]

Door initiatieven als https://letsencrypt.org/ denk ik dat het vanaf 2015 een stuk makkelijker wordt om je website gratis en vooral makkelijk te beveiligen via HTTPS.

Ik schrik van Google's plan, maar zolang het aangemoedigd wordt (of makkelijker is) om geen TLS/SSL te gebruiken dan wél zal de markt zich niet ontwikkelen. Gecombineerd met een initiatief als https://letsencrypt.org/ kan dit plan ervoor zorgen dat eenvoudige domain-validated certificaten gratis worden en zal waarschijnlijk ook de bijbehorende tooling zich moeten evolueren.

[Verwijderd]

Geld is het probleem niet. Een bedrijf of zzp-er die niet 10 euro per jaar kan missen kan beter gewoon stoppen. Veel kleine bedrijven kunnen besparen door alleen al te switchen van hoster. Veel bedrijfjes blijven hangen op een veel te dure webshoster.

Het grote probleem is de effort die ze moeten doen. Het aanvragen en invullen van de certificaatgegevens kost tijd. Als je niet dagelijks certificaten aanvraagt en plaatst dan tijd. En dan moet het ook nog jaarlijks (of elke x jaar mocht je een langere geldigheid willen).

Ik verwacht daarom niet zo snel "geleende" certificaten.

Wat ik wél verwacht is dat er bedrijfjes (en zzp-ers) actief websiteeigenaren gaan benaderen, net als die SEO boeren die een beetje linkbuilding voor honderden euro's verkopen.

Persoonlijk denk ik wel dat het een goede zaak is om SSL te forceren. Ik denk alleen dat als Google een dergelijke keuze maakt ze dan ook een soort van morele verplichting hebben om te helpen met goede handleidingen, voorbeelden, plugins en eventueel zelfs certificaten.

[Vexxon]

Toch duren sommige dingen dan weer heel erg lang, ik noem html 5 of de invoering van ipv6.

[gimbal]

HTML 5 is een zeer slecht voorbeeld. De ondersteuning begon al lang voordat de standaard uberhaupt klaar was, dat is TE snel.

[Vexxon]

Maar de uiteindelijke specificatie van html 5 heeft jaren geduurd.

[InsanelyHack]

De reactie van freedzed6 is helemaal zo gek nog niet. Een nuchtere relativering is best gepast op dit bericht. Als je dit nieuwsbericht leest, waarbij HP -> Google de schijn wil wekken dat het begaan is met de veiligheid van de gebruikers op internet en dat ook nog eens betiteld met "bewustwording" dan is dat plausibel. HP -> Google staat namelijk toe, net als ieder ander Amerikaans bedrijf, de informatie (dat kan natuurlijk best iets anders zijn dan http) te delen met de overheid door de Patriot Act. Hoe ze dat doen kan op vele manieren maar dat ze het doen of kunnen doen staat als een paal boven water. Zeker gezien de volumes van het (internet) netwerkverkeer dat ze transporteren transporteren. Nu is dit bij de concurrenten niet anders maar toch kan ik me de nare smaak in de mond die freedzed6 heeft wel een beetje voorstellen. Alleen willen mensen dit soort dingen niet meer horen en willen ze ook wel eens iets positiefs horen zonder dat het weer door de NSA | Patriot Act besmette wetgeving wordt afgezwakt terwijl iedereen het wel weet.

Edit helemaal stom HP geschreven maar dat moest natuurlijk Google zijn.

[Reactie gewijzigd door InsanelyHack op 23 juli 2024 01:21]

[Liberteque]

Nou dat had ik nu ook, enerzijds staat de deur open naar de NSA en god weet wat nog meer. Anderzijds worden alle sites door notabene een van de grootste internetbedrijven die ondertussen enorme hoeveelheden data doorsluist naar derde partijen (onder dwang vd Patriot Act of niet), gedwongen om naar https over te stappen.

Een heel groot gedeelte van het internet wordt gevuld met miljoenen leuke websites over muziek, videos, hamsters, houtbewerking, dansen en ga nog maar twee uur door. Hoe gaan we al die mensen die vanuit hun passie hobby en kennis met ons delen zover krijgen certificaten te plaatsen? Of gaan de ISP's dit op zich nemen? Dit gaat tijd en geld kosten. Wie gaat dat betalen?

Ik zie hier een enorme kans voor Google om het gigantische liggende kapitaal nu eens in te zetten om daadwerkelijk de hakken in het zand te zetten, de wereld definief af te helpen van http en een middelvinger op te steken naar de Patriot Act.

[jsnl]

Deze reaktie van Liberteque spreekt mij zeer aan, ben zo'n hobby website maker, heb hier al zo'n 15 jaar een eigen webservertje draaien zonder poespas, gewoon rechttoe-rechtaan (overigens is m'n webserver nog nooit uitgevallen in die tijd door aanvallen van buitenaf o.i.d.).
Betekent dit het einde van die hobby-sites, die wellicht niet spraakmakend zijn, maar wel degelijk voor velen info bevatten?

Heb enkele sites met vooral veel data, die ik nooit bij een goedkope webhosting provider kwijt kan, denk aan komplete backup van maritieme forums van vóór 2004, genealogie uitdraai, zo'n 90.000 html bestanden, etc.

[Verwijderd]

Ik ben het grotendeels met je eens maar ik snap niet waarom je van Google opeens HP maakt.
Anyhow, Google is een van de bedrijven die probeert HTTP 2.0 met daarin verplichte HTTPS te pushen. Dat levert extra kosten en overhead op terwijl dat voor het gros van de websites geen toegevoegde waarde heeft.
Sowieso lijkt het erop dat er meer security problemen zijn geweest met de beveiligde websites dan met het simpele basic authentication.
Okay, dat laatste helpt geen greintje tegen een man-in-the-middle, maar dat idee heb ik ook niet echt bij HTTPS. En van buitenaf is basic authentication best lastig, zeker in combinatie met fail2ban.

[torp]

HP?

[aZuL2001]

Alsof een website via https per definitie veilig is.

Https is, imho, nuttig in bepaalde gevallen (inloggen / transacties etc) maar voor "gewoon" het bekijken van info voegt het weinig toe.

[Alex)]

Om Scott Hanselman te citeren:

HTTPS & SSL doesn't mean "trust this." It means "this is private." You may be having a private conversation with Satan.

Voor het eerste heb je EV-SSL (de 'groene balk'). Voor het tweede volstaat ieder certificaat dat is afgegeven door een vertrouwde partij (de Verisigns van deze wereld).

[MoonWatcher]

Mee eens. Zolang je niet hoeft in te loggen is http prima.

Sterker nog, met alle rondzwervende SSL exploits kan het er zelfs minder veilig op worden!

Als we er nu voor gaan kiezen om ALLE web traffic cpu intensief te maken door er encryptie op toe te passen is er ook significant meer server hardware nodig. Ook het aantal vereiste IP adressen zal rap stijgen. Aangezien over het algemeen nog steeds de regel geld. 1 certificaat = 1 ip. ( ja SNI voor meerdere certificaten per IP bestaat al een tijdje en nee, het is nog steeds geen realistische optie. ) Met IPv6 geen probleem natuurlijk, maar dan zal dat wel sneller breder geaccepteerd moeten worden.

Ik zie dus nog wel een paar hekelpuntjes.

[- peter -]

Google gebruikt zelf ook SNI dacht ik, dus zo onrealistisch is dat niet meer tegenwoordig.

[CAPSLOCK2000]

Als we er nu voor gaan kiezen om ALLE web traffic cpu intensief te maken door er encryptie op toe te passen is er ook significant meer server hardware nodig. O

In de meeste gevallen is het verwaarloosbaar. De meeste webservers staan toch de hele dag niks te doen. Alleen hele grote websites zullen het merken.

( ja SNI voor meerdere certificaten per IP bestaat al een tijdje en nee, het is nog steeds geen realistische optie. ) Met IPv6 geen probleem natuurlijk, maar dan zal dat wel sneller breder geaccepteerd moeten worden.

Hoezo niet? Volgens mij bestaat dat probleem niet meer sinds WinXP+IE6 toch nergens meer wordt ondersteund.

[Jan-E]

SNI is tegenwoordig wel een realistische optie. Android 2.3, IE6 en IE8 op XP, Java 6, Bingbot en Yahoo Slurp ondersteunen geen SNI, maar alle andere gangbare clients wel. Zelfs IE8 op Windows 7 slikt SNI als zoete koek. Check:
https://www.ssllabs.com/s...nportal.net&s=89.31.102.7

[Verwijderd]

Het gaat er om dat er niet kan worden meegeluisterd. En dat is een uitstekend idee, op welke manier dan ook.

[jpfx]

Meeluisteren heeft enkel zin als er twee richting verkeer is. Voor websites die enkel informatie serveren zonder dat ik als gebruiker input hoef te geven (lezen van een review bijvoorbeeld) zijn helemaal niet interessant om mee te luisteren. Ergo: https is dan overkill, een rode adresbalk met een gevarendriehoek is dan pure paniekzaaierij en bezorgt je een onterecht gevoel van onveiligheid. Eigenlijk precies wat terroristen ook proberen te realiseren. Door op plaats A iets te doen moet je op plaats B, C, D, E, F, etc onveilig gaan voelen.

[Jace / TBL]

Meeluisteren heeft enkel zin als er twee richting verkeer is. Voor websites die enkel informatie serveren zonder dat ik als gebruiker input hoef te geven (lezen van een review bijvoorbeeld) zijn helemaal niet interessant om mee te luisteren

Mwoah, als ik allerlei informatie opvraag over aids en kanker, heb ik liever niet dat derden dat kunnen loggen en die informatie eventueel kunnen doorverkopen aan verzekeringsmaatschappijen. Of dat je googled op zwangerschap, op het moment dat je als vrouw bij de overheid wilt solliciteren. Om maar iets te noemen. Het gaat derden gewoon geen reet aan wat je allemaal bezoekt, ook als het alleen passief informatie binnenhalen is zonder interactie.

[jpfx]

Zodra je zoekt (google?) ben je interactief bezig.
Zodra je een website bezoekt (al typ je de url handmatig in) wordt je IP gelogged door je ISP en weten ze dus welke data je bekijkt.

Heeft allemaal niets met https te maken.

Je voorbeeld van verzekeringsmaatschappijen: het landelijk schakelpunt (het "nieuwe" EPD, wordt voor een groot deel gefinancierd door verzekeringsmaatschappijen en die hebben ook een vinger in de pap wat betreft beheer. Ik hoop dat je hebt gecontroleerd dat je artsen je daar niet ongevraagd bij hebben aangemeld (mogen ze niet!). Anders is het een kwestie van tijd tot "per ongeluk" de zorgeverzekeraars toch inzicht hebben in je medische gegevens.

Sterker: ook nu weten ze al een hoop aangezien artsen moeten declareren met zeer specifieke behandelcode's om betaald te krijgen. De verzekeraar weet dus al haarfijn wat je mankeert.

[Jace / TBL]

Zodra je zoekt (google?) ben je interactief bezig.
Zodra je een website bezoekt (al typ je de url handmatig in) wordt je IP gelogged door je ISP en weten ze dus welke data je bekijkt.

Ze weten alleen met welk IP ik verbinding maak, niet welke URLs ik bezoek of welke data ik bekijk of verstuur.

Google gebruikt al lang standaard HTTPS, dus ook mijn search queries aldaar worden 1-op-1 tussen mij en google gecommuniceerd, zonder meegluren van de provider of andere derden. Die kunnen alleen achterhalen dat ik waarschijnlijk google.com bezoek, niet op welke termen ik zoek.

Heeft allemaal niets met https te maken.

Juist wel, want HTTPS (SSL) zorgt ervoor dat behalve de DNS resolve, dus het eenmalig resolven van domeinnaam (niet URL!) naar IP-adres, er verder niets zichtbaar is voor derden (zoals de NSA of je ISP).

Je voorbeeld van verzekeringsmaatschappijen: het landelijk schakelpunt (het "nieuwe" EPD, wordt voor een groot deel gefinancierd door verzekeringsmaatschappijen en die hebben ook een vinger in de pap wat betreft beheer. Ik hoop dat je hebt gecontroleerd dat je artsen je daar niet ongevraagd bij hebben aangemeld (mogen ze niet!). Anders is het een kwestie van tijd tot "per ongeluk" de zorgeverzekeraars toch inzicht hebben in je medische gegevens.

Uiteraard heb ik daar een NEE ingevuld, en expliciet aangegeven dat mijn info daar NIET in mag.
In de praktijk helpt het helaas geen reet, en betekent dat vinkje dat je gegevens er toch inkomen, maar dan met een extra boolean "deze info mag niet gedeeld wordt". Maar het staat er toch gewoon in, dus de eerste de beste medewerker of hacker of malafide admin of verzekeraar kan ermee doen wat hij wil.

Sterker: ook nu weten ze al een hoop aangezien artsen moeten declareren met zeer specifieke behandelcode's om betaald te krijgen. De verzekeraar weet dus al haarfijn wat je mankeert.

Zeker. Maar dat is beperkt zich vooralsnog tot dingen waar ik mee naar de dokter ben geweest. Als ik op eigen gelegenheid ga zoeken op cholera en builenpest, kan de overheid of verzekeraar daar geen lucht van krijgen. Althans, mits de sites in kwestie HTTPS gebruiken.

[Verwijderd]

Jij kunt nu niet bepalen wat wel en niet interessant is. Wat vandaag relatief onschuldig leesvoer lijkt te zijn kan op een later moment een reden zijn om je op te pakken en in de cel te gooien, of erger.

Kijk eens naar IS in Irak bijvoorbeeld.

[jpfx]

Dat heeft dan weer niets te maken met of een site wel of niet https is. Dat je die site bezoekt kan evenzogoed worden opgeslagen.

[SuperDre]

Alleen jammer dat er inmiddels al wel meegeluisterd kan worden op https... het is al lang niet meer zo veilig als sommige mensen doen geloven...

[Jace / TBL]

Hoe dan? Meer dan het domein (op moment van DNS request) kun je niet echt onderscheppen toch?

[M.l.]

Een mitm is vaak makkelijker te doen over http omdat alles oncersleuteld is. Niet alleen is er te zien welke informatie wordt opgevraagd maar ook kan informatie/data worden vervalst. Denk aan trojaanse paarden in downloads. Er zijn nog veel sites waar handige tools te downloaden zijn, maar dat gaat alleen over http en de lijst met checksum (als die era is) wordt ook niet aangeboden over https.

[WhatsappHack]

Het is nu al erg genoeg dat zelf uitgegeven certificaten en zelfs domein certificaten door Chrome als onbetrouwbaar worden beschouwd.

Toch is dat logisch. Het is wel wat over de top, maar niet geheel vreemd.
Immers kan inderdaad de authenticiteit niet geverifieerd worden, de browser kan dus niet vaststellen of de verbinding inderdaad veilig is.
Als je echt belangrijke info moet overpompen of je wordt het slachtoffer van de een of andere aanval, is het niet meer dan logisch dat zo'n certificaat reden is tot waarschuwing. Immers kan je niet zeker weten of de verbinding daadwerkelijk veilig is.

Door de vele incidenten met certificaat uitgevers, is geen enkele certificaat veilig te noemen. Immers zolang incident niet aan het licht Is gekomen weet men niet dat certificaat onrechtmatig Is.

Ja zo ken ik er ook nog wel een paar.
Als door incidenten niets meer vetrouwd kan worden, en dus alle CA's opeens niet meer veilig zouden zijn, dan kan je dat wel doortrekken naar heel veel applicaties; en niet enkel op IT gebied. Dan mag je de hele tijd paranoide zijn dat niets veilig is.
ALS je werkelijk iets zeer gevoeligs moet versturen is dat natuurlijk geen slecht plan, maar voor dagelijks huis-tuin-keuken gebruik zijn CA's gewoon betrouwbaar, een stuk betrouwbaarder dan self-signed certificaten in ieder geval.
Het wil niet zeggen dat self-signed per definitie inderdaad onveilig is, helemaal niet zelfs; maar verifieerbare certificaten hebben toch net een tandje voor.

Verder was het in pre-Snowden tijdperk al algemeen bekend dat RSA en meeste Israëlische bedrijven nauwe banden met NSA en CIA hebben. De gebruikte encryption voor SSL kan je derhalve niet vertrouwen.

Die is nog prima te vertrouwen.

Verder consumeert SSL veel computing resources waardoor je maar een fractie aan sessies (dus bezoekers) tegerlijkerktijd kunt hebben. Je jaagd hiermee bedrijven, organisaties en kleine weloverwogen op kosten.

Dat is wel heel erg overdreven. Ja SSL geeft wat overhead en heeft meer resources nodig, maar het heeft niet zo'n dusdanige impact dat je opeens nog maar 5% van je normale traffic kan hebben of iets dergelijks. Ja tenzij je nog op een Pentium 3 servertje draait ofzo, maar dan kon je sowieso al niet zoveel hebben.
Je overdrijft enorm.

Dat de browser een melding geeft dat de verbinding onveilig is, kan al met bijvoorbeeld enkel het sleuteltje rood met een kruisje laten zijn zoals nu het geval is bij onverifieerbare SSL certificaten. Niemand wordt VERPLICHT om SSL in te zetten.
Dat zou ook onzin zijn. Voor oma's hobby kooksite waar ze wat recepten opzet heb je echt geen SSL nodig.
Wat wel noodzakelijk is, maar wat veels teveel sites nog nalaten, is dat inloggen, zeker als dit niet pre-hashed wordt aan de client-side, over SSL heengestuurd wordt.
Dat is zeker wel belangrijk, en zou, zelfs als wat jij zegt waar is dat het zo'n gigantische overhead geeft, enkel het aantal login pogingen dat je tegelijkertijd kan afhandelen limiteren; niet het bezoek aan de gehele site.

Kortom, zelfs als je zo'n brakke servert hebt dat je nauwelijks traffic aankan en SSL een doodsteek zou zijn kan je nog manieren vinden om het werkbaar te maken zodat enkel het noodzakelijk beveiligd is, en al het niet noodzakelijke gewoon plain wordt uitgewisseld.

Tot slot wek je valse verwachtingen en schijnheiligheid. Wie zegt dat jij je browser kunt vertrouwen? Je wintendo of enig ander OS? Mocht je die vertrouwen vertrouw jij je Intel moederbord en chips en dito cpu?

Wie zegt dat je je computer kan vertrouwen? Je internet provider? Je vrouw en/of kinderen? Je buurman? Je buschauffeur? De kok in het lokale restaurant?
Je kan zo paranoia zijn als je wilt, maar donder dan meteen je computer gewoon helemaal het huis uit.

Geheel veilig bestaat niet, zo veilig mogelijk wel: en dat is waar het om draait en wat belangrijk is.

Verder vind ik persoonlijk Google maar ook een Apple en een Microsoft een veel grotere risico dan een westerse overheid die in mij porno zit te grasduinen.

De overheid is niet geinteresseerd in jou porno.

[Blokker_1999]

Bij self-signed certificaten waarbij je "signing parties" organiseert waarbij mensen fysiek sleutels uitwisselen, is er tenminste geen sprake van een derde partij waar je geen controle over hebt.

Maar je hebt ook geen enkele mogelijkheid om na te gaan dat wat je tekent correct is. Bij een domeinvalidatie word nagegaan of je effectief toegang hebt tot het domein, bij een EV validatie word een degelijke controle uitgevoerd door de CA. Bij een signing party kan je zeggen: hallo, ik ben google.com, wil je even ondertekenen?

O.a. Amerikaanse overheid zal (zeker niet in deze tijd) kenbaar maken hoever ze zijn met quantum computing en dat ze daarmee alle gebruikte encryptie in een hand omdraai mee kunnen kraken maakt alles wat je nu doet om nieuwsgierige overheden buiten te houden overbodig.

Amerikaanse overheid word al jaar en dag overschat in hun mogelijkheden. Ja, ze luisteren veel af, maar dat is vooral omdat wij hen net de mogelijkheid geven om af te luisteren. Als al die projecten zo goed zouden zijn en zo machtig en krachtig, dan had 9/11 nooit kunnen gebeuren.

Aan de andere kant.... waarom voor WEB SSL gebruiken....(verplichten zelfs), terwijl de meeste mensen SMTP, POP, FTP en IMAP gebruiken voor wel gevoelige informatie die onversleuteld over de lijn gaat..

Men moet ergens beginnen. Als je bekijkt dat men vandaag al opziet tegen het implementeren van SSL op de webserver, hoe moet dat dan om dit verder uit te rollen naar andere diensten?

[totaalgeenhard]

Root CA kan niet beoordelen of de gegevens die jij verstrekt authentiek zijn. Ze gaan niet bij kadaster en gemeente controleren of bedrijf ergens gevestigd is. Of kvm uittreksels opvragen.

Bovendien zelfs douane heeft moeite met controleren van een paspoort, vandaar biometrische laag die extra hindernis vormt.

Een fake passport of ID kost maar honderden euro's en zonder deze fysiek in handen te hebben (scan) en toegang paspoort database weet je niets.

Om maar te zwijgen over landen die bedrijfs registratie niet geautomatiseerd hebben en derhalve documenten net zo gogoed vervalst of door omkoping verkregen zijn.
Er zijn landen waar paspoort en kvk uittreksels handmatig ingevuld zijn.

En dan moet men nog altijd er vanuit gaan bij root ca er competente mensen werkzaam die in een vreemde taal een vreemde document moeten beoordelen op rechtsgeldigheid.... om maar te zwijgen over integriteit van medewerkers en management.

Nederlandse overheid wilde root CA worden zodat je als bedrijf via hun gevalideerde certificaat kon krijgen ik weet niet wat status Is van dat project. Maar Nederlandse overheid is enige partij die met hoge mate van zekerheid een (rechts) persoon kan verifiëren.

Nu gaf jij aan certificaat voor Google. Com niet zo makkelijk te verkrijgen zal zijn. In eerste instantie deel ik je mening, hi-profile zullen nauwkeuriger worden gecontroleerd omdat het bij iemand als zodanig herkend zal worden... maar denk je dat een doorsnee Amerikaanse medewerker van een root CA van SNS of fortis heeft gehoord?

Bovendien maakt dat niet zoveel uit als je als overheid hele infrastructuur in handen hebt, kunnen zei bepalen wat je ziet. De chromebrowser die jij denkt te downloaded kan net zo goed van een overheid site afkomen en gemodificeerd zodat jij ziet dat alles "veilig" is terwijl er een man in the middle attack gaande is.

Je moet ergens beginnen maar dan wel goed en niet protocollen gebruiken die nooit rekening hebben gehouden met politieke/militaire motieven.

Als elk land eigen Pki zou hebben zul je alleen op kleine schaal misbruik kennen (spionage/geheimediensten) bovendien zou kosten voor certificaat terug gebracht kunnen worden tot iets wat je op den duur gratis krijgt. Nieuw OS even je ID fotograferen, biometrische meting en OS weet dat jij iemand bent en vandaar verder.

Ps: er zijn valide certificaten in om loop geweest voor high profile sites... gehacked welliswaar maar welke garantie heb jij dat als jij nu maar gmail gaat jij nu geen gebruik maakt van een certificaat die vandaag speciaal voor jouw Is afgegeven? Controleer jij elke certificaat met je eigen ogen? Elke dag?

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 01:21]

[flippy]

en dan gaat het hele concept onderuit want dan kijkt er niemand meer na zoals men bij bankieren doet.

[Verwijderd]

Bovendien geeft het een gevoel van schijnveiligheid.
'o, de site is groen, dan is het veilig'. Waarna de argeloze gebruiker gewoon usernames en wachtwoorden gaat invullen. Het/een certificaat geeft aan dat een geserveerd domein een gevalideerde naam heeft; niet of de site bonafide is.

[Soultaker]

Het garandeert ook dat de uitgewisselde informatie niet onderweg door derden is af te luisteren. Dat is pure winst ten opzichte van de huidige situatie.

[NLsandman]

Niet blij mee, we hebben een kleine clan met website en server, nu forceert google ons
om https te gebruiken wat ook weer geld kost, het idee er achter is niet verkeert maar laat
google maar certificaten gaan uitgeven voor ons, die hebben geld zat.

[Blokker_1999]

google forceerd niets. Ze komen met een voorstel en vragen feedback.

[Verwijderd]

Die er vervolgens door Google doorheen gedrukt wordt. Sorry hoor, maar 'vragen' is één. Bij voorbaat staat al vast dat Google dit gaat doen. Dat is twee. Let maar op!

Google gaat dit plan gewoon doorzetten. Ook als een overgrote meerderheid tegen is.

[CAPSLOCK2000]

Er zijn meerdere aanbieders van gratis certificaten, bv https://www.startssl.com en https://www.letsencrypt.org/ is er ook mee bezig.

[Verwijderd]

Nooit voor wildcard certificaten voor mensen die subdomains gebruiken.

[Verwijderd]

Het verwaterd 'een echte' onveiligheidsmelding.

Op lange termijn zorgt het ervoor dat alle sites https worden,
Wat wel een vooruitgang is.

[Quas]

https is een ding.

Misschien moet er zoiets komen als een geverifieerde site. Als je kan bewijzen dat de Eigenaar van het domein ook de eigenaar is van het bedrijf. Hierdoor krijg je dus een veilige verbinding maar ook een bewijs dat de website ook echt van de eigenaar is.

Stel je voor dat straks en lNG.nl ook https verbinding heeft, dan trapt vast half nederland erin. Jij vast ook want er staat eigenlijk LNG.nl of lng.nl . Hiervoor moet dus iets komen van een controle mechanisme, via de kamer van koophandel misschien. Want een lng mag dan natuurlijk nooit een veiligheidskeurmerk krijgen voor een domein.

Hoe het precies moet werken, ja geen idee, of de kosten en winst en ondersteuning door browsers is en blijft vaag. Het is ook maar een hersenspinsel maar ik zie er wel wat in.

Want elke gek kan een https verbinding opzetten met zijn server, wat hij dan doet met die data, of wat überhaupt de bedoeling is blijft altijd vaag.

Edit: Dankje @CAPSLOCK2000 het bestaat dus al. http://nl.wikipedia.org/wiki/Extended_Validation-certificaat

[Reactie gewijzigd door Quas op 23 juli 2024 01:21]

[opposite]

Laten we alsjeblieft de KvK erbuiten laten. Iets dat Kvk geregistreerd is zegt helemaal niks. De enige garantie is dat ze je gegevens doorspelen zodat je platgebeld kan worden door callcenters met slechte aanbiedingen

[ongewoongewoon]

En spookfacturen, ik had er al 1 binnen 14 dagen na inschrijving

[noobz]

Nee, die rekening van 30 euro van de KvK is echt.

[hackerhater]

50 euro bedoel je

[hackerhater]

De KVK hoeft niet actief de gegevens door te spelen. Als ondernemer kan je (tegen betaling) die gegevens gewoon inzien (openbare contact info!).

Dat kan ten goede gebruikt worden (check of een bedrijf echt bestaat ed) en ten slechte (nutteloze reclame).

[Aikon]

Op zich een goed voorstel, ware het niet dat dat nou precies is wat een certificaat eigenlijk zou moeten bewerkstelligen. In principe krijg je enkel een certificaat als je je kan identificeren als eigenaar v/h domein en bedrijf etc.

Wat als ik het bedrijf Lng.nl begin en dan een certificaat aanvraag? Allemaal legitiem natuurlijk.

[revertive]

Beetje slecht voorbeeld aangezien www.lng.nl een website over liquefied natural gas is. Maar ik snap je punt, en daar heb je nou ook al last van dus in dit geval veranderd er niet veel.

[CAPSLOCK2000]

Dat bestaat, het heet een EV-certificaat (extended validation). http://nl.wikipedia.org/wiki/Extended_Validation-certificaat

[DigitalExorcist]

Ik zie je edit nu pas, maar inderdaad, je hebt simpele validatie, domein validatie, en nog een gradatie hoger waarbij de eigenaar van het domein dus moet aantonen dat hij echt de eigenaar is, en het bedrijf dat hij zegt te vertegenwoordigen ook echt is.

[sfranken]

Nee, de "echte" meldigen zijn in-your-face (rood scherm des doods word het gekscherend genoemd). Die negeer je echt niet zomaar, een kleurtje in je adresbalk is relatief snel te negeren.

[jpfx]

Zodat we een "veilig" gevoel hebben terwijl dat wellicht helemaal niet zo is. Volgens mij is het een kwestie van tijd totdat blijkt dat ook hier gewoon al jaren een backdoor in zit of de bewuste hacker zorgt dat er een (tijdelijk) geldig certificaat wordt geserveerd die toch niet vertrouwd is en rustig malware serveert. Dan ben je dus weer terug bij af.

Bewust maken is één ding. Of een niet https pagina onveilig is hangt vooral af van wat er op de betreffende pagina gebeurd.

[runelaenen]

Als ze dan de certificaten wat goedkoper/gratis maken :-/

[Juwel]

Gemiddels kan je voor 12 USD al een SSL certificaatje krijgen, op zich niet zo veel voor toch?
Maar ja, als je meerdere sites hebt tikt het wel wat aan.

[Reactie gewijzigd door Juwel op 23 juli 2024 01:21]

[runelaenen]

Dan moet je al jaarlijks een domein + certificaat gaan betalen. Als het een hobby is (zoals bij mij) zonder inkomsten vind ik dat wel wat veel als je enkele websites hebt...

[ddbc]

Volgens mij zijn er ook gratis alternatieven hoor, moet je maar eens googlen

[Verwijderd]

Dat is vaak voor 1 domein. Heel veel mensen hebben ook nog subdomeinen.
Dan lopen de kosten al heel snel op, omdat je voor ieder subdomein een apart certificaat nodig hebt of een heel duur *.domein certificaat.

[pennywiser]

Vertel, welke.. ben heel benieuwd.

[Soldaatje]

https://en.wikipedia.org/wiki/StartCom

Firefox heeft deze extensies die ongeveer doen wat Google wil:
https://addons.mozilla.or...n/calomel-ssl-validation/
https://addons.mozilla.org/en-US/firefox/addon/safe/

[Reactie gewijzigd door Soldaatje op 23 juli 2024 01:21]

[pennywiser]

No commercial use
Certificate revocation requires a fee

[Pilovali]

CloudFlare heeft sinds een aantal maanden gratis SSL voor iedere gebruiker (ook gratis).

[OverSoft]

Deze worden alleen door geen enkele grote browser geaccepteerd... Dus daar heb je weinig aan...

[halfgaar]

Startcom wordt bijna overal geaccepteerd.

[PerfectPC]

Tuurlijk wel, enkel de hele oude browsers hebben er soms wat last mee.

[OverSoft]

Noem dan eens een gratis SSL provider die in alle browsers geaccepteerd wordt? CA cert bijvoorbeeld al niet, en dat is de grootste voor zover ik weet.

[XIU]

https://www.startssl.com/

[OverSoft]

Ik neem mijn woorden terug, zal morgen eens testen. Overigens zullen er wel meer dan 1 aanbieder moeten komen voor gratis certificaten, omdat je anders je complete vertrouwen op een bedrijf legt.

[Keffa18]

Ik gebruik zelf een startssl cert voor mijn exchange, enige apparaat dat ooit problemen gaf was een WP7 telefoon. Echter was dit met het importen van de root ca zo opgelost.
Verder wordt het door elke browser geaccepteerd.

[PerfectPC]

Er zouden inderdaad meer gratis (of goedkope) alternatieven moeten komen, daar heb je gelijk in.
Mocht je een wildcard (class2) cert van startcom willen testen: https://rumst.verbert.be

[RobinJ1995]

Heb ik een tijd getest. Wordt geweigerd door Firefox.

[Verwijderd]

Die zijn niet goed genoeg.

[henry906]

helemaal mee eens, als je voor elke site die je maakt een certificaat moet kopen, ben je gauw een stuk armer

[NTAuthority]

Dan vind ik dat eerst a) certificaten altijd gratis moeten zijn, zelfs voor multi-domain (zodat geen onnodige CSRs aangemaakt moeten worden) en b) er wat gedaan moet worden aan de problemen die TLS oplevert bij trage verbindingen zoals slechte mobiele datavebindingen.

[feuniks]

Dan vind ik dat eerst a) certificaten altijd gratis moeten zijn, zelfs voor multi-domain (zodat geen onnodige CSRs aangemaakt moeten worden) en b) er wat gedaan moet worden aan de problemen die TLS oplevert bij trage verbindingen zoals slechte mobiele datavebindingen.

Ow. Ik vind juist dat certificaten dan een stuk duurder moeten worden. Immers als alles https wordt, dan staat er bij elke site een sleuteltje. Ik krijg mijn moeder nu al niet uitgelegd dat de link http://www.WijGaanUwBankr...x.php?www.UwBank.nl/login niet naar haar bank gaat. Als dat dan ook nog een https wordt met een certificaat, dan is het helemaal problematisch, want dan is het toch zoals de folder van de bank zegt...

[Blokker_1999]

Alleen maakt je bank gebruik van een EV certificaat, en dat valt vandaag toch echt wel op tov een domain verified certificaat.

[eborn]

Tweakers wel. De gemiddelde gebruiker niet.

[keesdewit]

Gratis = Geen CSR? Leg eens uit?

[NTAuthority]

note 'onnodige', omdat momenteel de paar gratis/goedkope certificaten nog altijd enkel een enkele CN hebben

[keesdewit]

Een CSR (PKCS#10) is niet onnodig omdat er een enkele CN aanwezig is. Het is een manier om je certificaataanvraag ondertekend te krijgen door je (gratis) CA zonder dat het prive gedeelte van het certificaat bij de CA komt. Alle andere manieren download je een compleet certificaat met privésleutel bij de CA en dat is minder veilig.

[Reactie gewijzigd door keesdewit op 23 juli 2024 01:21]

[sanderv]

Ik vind dit een slechte ontwikkeling. Er zijn voldoende sites waarvan ik het als gebruiker niet nodig vind om deze via https te bezoeken. Als gebruiker maakt het me niet veel uit. Maar ik heb ook wel een paar sites waar het me als hobby-beheerder wel degelijk waar uitmaakt en ik geen zin heb om ook nog eens tijd te moeten besteden aan het configureren van certificaten.

[Reactie gewijzigd door sanderv op 23 juli 2024 01:21]

[Aikon]

Ik snap je punt, maar ik denk dat dat puur een kwestie van communicatie zal zijn. Als er duidelijk wordt aangegeven dat de communicatie kan worden onderschept, dan kan een ieder (bezoeker of beheerder) voor zich bepalen of dat een bezwaar is.

[Sissors]

Echter ik vind dan weer dat het een onterecht idee van onveiligheid geeft. Vooral omdat google dus niet een kleurtje voor http wil hebben (die is er al: wit), maar omdat google expliciet http als onveilig wil neerzetten. Waarbij dus de gemiddelde internetter zich veel meer zorgen gaat maken dan nodig is, waarom zou ik een nu.nl, tweakers.net of xkcd met https willen bezoeken?

[sanderv]

Zeker, en het hangt er ook maar net vanaf hoe het gecommuniceerd wordt. Maar nu krijg ik het idee dat het dezelfde koebellen gaat krijgen als invalide certificaten, en dat vind ik toch echt van een andere orde. Laat mij mijn site runnen zonder certificaat, mag een gebruiker toch zelf weten of hij daar zijn gegevens op wil achterlaten of niet? Als je helemaal geen sites wenst te bezoeken die geen https ondersteunen (Tweakers willen dat misschien, veel mensen zuller er niets om geven) dan kun je de instellingen wel wat tweaken.

[qlum]

Ik denk dat het dwingen van ssl gewoon volstrekt onnodig is, waarom zou een receptensite nu weer over een beveiligde verbinding moeten lopen, tuurlijk kan het allemaal wel maar naar mijn mening volstrekt onnodig

[WhatsappHack]

Niemand wordt gedwongen, er wordt enkel een melding gegeven zodat mensen weten dat de verbinding onveilig is... Gewoon een geheugensteuntje, nothing more. Prima plan if you ask me.

[Verwijderd]

Ik krijg ook niet de melding dat autorijden onveilig is als ik het contactslot omdraai....

Helemaal geen goed plan dus. Het is alleen een vorm van schijnveiligheid.

[WhatsappHack]

Autorijden is ook helemaal niet onveilig, tenzij jij er zelf voor kiest om met 160KM/h tegen het verkeer in op een file in te rijden... Zulke vergelijkingen slaan natuurlijk nergens op.
Autorijden is even gevaarlijk als veilig naar wat je er zelf van maakt, weinig kans op een ongeluk als je jezelf gewoon netjes gedraagt.
Maar als jij een waarschuwing krijgt dat autorijden onveilig is als je het contact omdraait, maakt dat het voor jou totaal niet veiliger... Op welke manier zou dat in godsnaam opeens veiliger of onveiliger worden of een idee van schijnveiligheid wekken?
Echt, het slaat helemaal nergens op wat je daar nu roept.

Het gaat hier dan ook helemaal niet om een vorm van schijnveiligheid. Schijnveiligheid is als er gezegd wordt dat iets veilig is, terwijl dat niet zo is.

Het enige dat dit doet is je eraan herinneren dat je verbinding totaal geen beveiliging heeft. Als jij dus een wachtwoord formuliertje invult en opeens ziet dat de verbinding onveilig is, kan je er nog voor kiezen om het dan maar niet te versturen. Dat is erg handig...

En hoe je het ook wend of keert: een verbinding met SSL is toch echt veiliger dan een verbinding zonder SSL, dus van schijnveiligheid is hier echt werkelijk op geen enkele wijze sprake... In de verste verte niet.

Het is een super goed plan.

[CAPSLOCK2000]

Omdat kleine receptensites groot worden en vroeg of laat een log-in functie toevoegen en dan moet je maar hopen dat ze beseffen dat ze dan HTTPS nodig hebben.

[totaalgeenhard]

SSL om wachtwoorden af te schermen is handig maar als iemand al bij je verkeer kan dan heb je ander probleem.

Veel mensen hebben niet door dat als je verkeer kunt onderscheppen (sniffen) de stap naar zelf manipuleren ook tot mogelijkheden zal behoren. En daar helpt niets tegen.

Sinds ver voor Christus werkten legers met versleuteling van informatie gebaseerd op sleutels die vooraf en fysiek gedeeld werden, zodat koerier die met versleutelde boodschap onderweg was en gepakt werd vertrouwelijkheid van boodschap niet prijs kan geven.

Anno 2014 is daar niets aan gewijzigd. Als je niet vooraf fysiek sleutels gaat delen (tijdens zogenaamde signing parties) weet jij nooit of een derde toegang heeft of niet.

Bovendien waarom zou iemand zijn wachtwoord willen verbergen en de rest van wat hij op een site doet niet?