{"id":181358,"date":"2016-09-10T01:33:00","date_gmt":"2016-09-09T23:33:00","guid":{"rendered":"http:\/\/www.borncity.com\/blog\/?p=181358"},"modified":"2016-09-10T15:11:05","modified_gmt":"2016-09-10T13:11:05","slug":"google-chrome-zeigt-http-seiten-demnchst-als-unsicher-an","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2016\/09\/10\/google-chrome-zeigt-http-seiten-demnchst-als-unsicher-an\/","title":{"rendered":"Google Chrome zeigt http-Seiten &lsquo;demn&auml;chst&rsquo; als unsicher an"},"content":{"rendered":"<p><img decoding=\"async\" style=\"float: left; margin: 0px 10px 0px 0px; display: inline;\" src=\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2015\/01\/Chrome.jpg\" \/>Google will das Web auf <em>https<\/em>-\u00dcbertragung zwingen, koste es, was es wolle. Demn\u00e4chst zeigt der Google Chrome-Browser Webseiten, die per <em>http<\/em> ausgeliefert werden, als unsicher an. Hier ein paar Infos und Gedanken zum Thema.<\/p>\n<p><!--more--><\/p>\n<h3>Zum Hintergrund: http oder https<\/h3>\n<p><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/ssl-vg03.met.vgwort.de\/na\/f1ca9653886349009dbc9ee00e23a5ee\" alt=\"\" width=\"1\" height=\"1\" \/>Webseiten k\u00f6nnen vom Server unverschl\u00fcsselt per <em>http <\/em>oder verschl\u00fcsselt per <em>https <\/em>ausgeliefert werden. Das Hypertext Transfer Protocol (<em>http<\/em>) unterst\u00fctzt jeder Webserver. Um Webseiten per <em>https <\/em>auszuliefern, sind \u00c4nderungen am Webserver erforderlich. Unter anderem muss ein Zertifikat vorhanden sein, welches die Identit\u00e4t des Webservers \u00fcberpr\u00fcfbar macht. Das bedeutet f\u00fcr den Website-Betreiber zus\u00e4tzliche Kosten und zus\u00e4tzlichen Aufwand. L\u00e4uft das Zertifikat aus, werden Zugriffe auf die Inhalte als \"unsicher\" gesperrt.<\/p>\n<p>Urspr\u00fcnglich war <em><a href=\"https:\/\/de.wikipedia.org\/wiki\/Hypertext_Transfer_Protocol_Secure\" target=\"_blank\">https<\/a> <\/em>daf\u00fcr gedacht, sensitive Daten w\u00e4hrend der \u00dcbertragung zwischen Server und Client zu verschl\u00fcsseln, so dass diese nicht gelesen und\/oder verf\u00e4lscht werden k\u00f6nnen. Dadurch f\u00e4llt auch die Umleitung auf \"gefakte\" Webseiten beim Phishing auf. Aber das kann man auch erkennen, wenn man sich die URLs der abgerufenen Seiten anschaut. Zwischenzeitlich ist davon auszugehen, dass diese https-verschl\u00fcsselten Daten von interessierten Stellen durchaus mitgelesen und sogar ver\u00e4ndert werden k\u00f6nnen. Aber das nur am Rande.<\/p>\n<h3>Das Vorhaben von Google<\/h3>\n<p>Schon seit l\u00e4ngerem versucht Google die \u00dcbertragung von Webseiten vom als \"unsicher\" eingestuften <em>http <\/em>auf <em>https <\/em>zu dr\u00fccken. Webseiten, die per <em>https <\/em>ausgeliefert werden, stuft Google im Ranking hoch.<\/p>\n<p>Nun gibt es den n\u00e4chsten Schritt: Ab Januar 2016 wird der Google Chrome-Browser in der Version 56 Webseiten, die <em>http <\/em>zur \u00dcbertragung verwenden, aber Passw\u00f6rter zur Anmeldung verwenden oder Kreditkartendaten \u00fcbertragen, als unsicher anzeigen. Es gibt vorerst nur eine Warnung \"Not secure\" oder \"Nicht sicher\" bei der Anzeige der Seite.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/4.bp.blogspot.com\/-rBbNGiLQzMw\/V9CudVXYkjI\/AAAAAAAAAWk\/SIol_AChYQITBcYJ34xcGsC0a7_VP755gCLcB\/s640\/blog%2Bimage%2B1.png\" width=\"566\" height=\"222\" \/><br \/>\n(Quelle: Google)<\/p>\n<p>Insgesamt ist das eine sinnvolle Geschichte, da Kennw\u00f6rter und Zahlungsinformationen nicht unverschl\u00fcsselt \u00fcbertragen werden sollen. Zu einem sp\u00e4teren Zeitpunkt will Google dann alle per <em>http<\/em> \u00fcbermittelten Webseiten bei der Anzeige im Inkognito-Modus als \"nicht sicher\" markieren. Wenn ich <a href=\"https:\/\/security.googleblog.com\/2016\/09\/moving-towards-more-secure-web.html\" target=\"_blank\">den Blog-Beitrag<\/a> von Google richtig interpretiere, sollen irgendwann alle per <em>http <\/em>\u00fcbertragenen Webseite im Google Chrome-Browser mit einem roten Dreieck gekennzeichnet werden. Dieses Symbol wird auch verwendet, wenn eine <em>https<\/em>-\u00dcbertragung als unsicher oder gebrochen eingestuft wird.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/3.bp.blogspot.com\/-DG70U0Y-y9w\/V9Cwuym53AI\/AAAAAAAAAW0\/6zO81T_hqWMjdAF_YYK7dfXV-26DL7OYACLcB\/s400\/blog%2Bimage%2B2.png\" \/>(Quelle: Google)<\/p>\n<p>Begr\u00fcndung ist, dass eine unverschl\u00fcsselt \u00fcbertragene Webseite mitgelesen und modifiziert werden k\u00f6nnte. Die Details sind in <a href=\"https:\/\/security.googleblog.com\/2016\/09\/moving-towards-more-secure-web.html\" target=\"_blank\">diesem englischsprachigen Blog-Beitrag<\/a> von Google zu finden. Und da fangen meine Probleme mit dem Google-Ansatz an.<\/p>\n<h3>Wo ich die Probleme beim Google-Ansatz sehe \u2026<\/h3>\n<p>W\u00e4hrend die <em>https<\/em>-\u00dcbertragung bei der Eingabe sensitiver Daten sicherlich sehr sinnvoll ist, versucht Google imho das \"Kind mit dem Bade\" auszusch\u00fctten. Millionen einfache Webseiten, die ein paar Informationen bereitstellen, sollen so auf die <em>https<\/em>-\u00dcbertragung \"gezwungen\" werden. Steigerung der Sicherheit? In meinen Augen Null. Warum?<\/p>\n<p>Es ist zwar korrekt, dass die \u00dcbertragung der <em>http<\/em>-Daten gelesen und modifiziert werden kann. Aber mitlesen kann jeder, der die URL der abgerufenen Webseite kennt. Solange der Benutzer keine sensitiven Daten in die Formulare einer Webseite eintr\u00e4gt, sehe ich das unkritisch.<\/p>\n<p>Und zum Thema \"Modifizierung der \u00dcbertragung\": die \"Hacks\" passieren doch an anderer Stelle. Ein kompromittierter Webserver, der Schadsoftware ausliefert. Super-Cookies, die von Werbetreibenden gesetzt werden, um das Surfverhalten der Nutzer zu verfolgen. Oder kompromittierte Werbenetzwerke (an denen Google ja auch beteiligt ist), die Malware ausrollen, das sind imho alles viel gr\u00f6\u00dfere Bedrohungen, als ein Man-in-the-middle-Angriff bei einer <em>http<\/em>-\u00dcbertragung. Einzig die \"Umleitung beim Phishing durch gefakte Webseiten\" k\u00f6nnte ggf. noch manchen Zeitgenossen retten \u2013 obwohl der die Warnung im Browser vermutlich ignoriert.<\/p>\n<p>Gehe ich noch einen Schritt weiter, wird sichtbar, wo es noch krankt. Die Hersteller von Internet Security-L\u00f6sungen unternehmen momentan alle m\u00f6glichen Klimmz\u00fcge, um sich in die <em>https<\/em>-Verschl\u00fcsselung einzuklinken und den Datenstrom der \"ach so sicheren\" <em>https<\/em>-\u00dcbertragung mitlesen und auf Schadsoftware \u00fcberwachen zu k\u00f6nnen. Und hebeln dann nicht selten die komplette <em>https<\/em>-Verschl\u00fcsselung durch fehlerhafte Implementierung aus (siehe z.B. <a href=\"https:\/\/borncity.com\/blog\/2015\/09\/03\/comodo-antivirus-killt-chrome-45-browser-per-code-injection\/\" target=\"_blank\">diesen Blog-Beitrag<\/a>). Und geklaute Zertifikate (siehe <a href=\"http:\/\/www.heise.de\/newsticker\/meldung\/SSL-GAU-zwingt-Browser-Hersteller-zu-Updates-1212986.html\" target=\"_blank\">hier<\/a>) rei\u00dfen ebenfalls Sicherheitsl\u00fccken auf. Also wird da wiederum ein gro\u00dfer Ballon aufgeblasen, der den Aufwand hoch treibt und die Sicherheit gelegentlich reduziert.<\/p>\n<p>Unter dem Strich: Hier wird in meinen Augen ein sinnvoller Ansatz, <em>https <\/em>da einzusetzen, wo sensitive Informationen \u00fcbertragen werden, konterkariert. Am Ende des Tages ist der Ansatz imho nur ein gigantisches Umverteilungsprogramm f\u00fcr Zertifikate-Aussteller, die die Zertifikate kostenpflichtig ausstellen und zyklisch erneuern k\u00f6nnen. F\u00fcr mich als Blog-Betreiber bedeutet das, dass ich mich um die jeweiligen kostenpflichtigen Zertifikate k\u00fcmmern, diese einbinden und auch pflegen muss. Macht Aufwand, ohne dass sich an der Sicherheit der \u00f6ffentlich abrufbaren Blog-Beitr\u00e4ge ein Jota \u00e4ndert.<\/p>\n<p>Wenn ich mir die Kommentare <a href=\"http:\/\/m.heise.de\/forum\/heise-online\/News-Kommentare\/Chrome-soll-vor-nicht-verschluesselnden-Webseiten-warnen\/Nein-Ich-sehe-da-jetzt-keinen-Gewinn\/posting-29176172\/show\/\" target=\"_blank\">hier<\/a>, <a href=\"http:\/\/m.heise.de\/forum\/heise-online\/News-Kommentare\/Chrome-soll-vor-nicht-verschluesselnden-Webseiten-warnen\/Wozu-neuerdings-unbedingt-alles-verschluesselt-werden-muss\/posting-29176121\/show\/\" target=\"_blank\">hier<\/a>, <a href=\"http:\/\/m.heise.de\/forum\/heise-online\/News-Kommentare\/Chrome-soll-vor-nicht-verschluesselnden-Webseiten-warnen\/Nein-Ich-sehe-da-jetzt-keinen-Gewinn\/posting-29176172\/show\/\" target=\"_blank\">hier<\/a>\u00a0oder <a href=\"http:\/\/m.heise.de\/forum\/heise-online\/News-Kommentare\/Chrome-soll-vor-nicht-verschluesselnden-Webseiten-warnen\/Noch-mehr-nervigen-Bloedsinn\/posting-29176964\/show\/\" target=\"_blank\">hier<\/a>\u00a0ansehe, bin ich nicht alleine.\u00a0In Zeiten, wo Millionen E-Mails per unverschl\u00fcsseltem Protokoll verschickt werden, erscheint mit der Google-Ansatz jedenfalls reichlich \u00fcberdimensioniert und kontraproduktiv. Aber m\u00f6glicherweise habe ich was \u00fcbersehen \u2013 oder gibt es von eurer Seite andere Insights? (<a href=\"http:\/\/www.zdnet.com\/article\/chrome-to-start-labeling-http-connections-as-non-secure\/\" target=\"_blank\">via<\/a>)<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Google will das Web auf https-\u00dcbertragung zwingen, koste es, was es wolle. Demn\u00e4chst zeigt der Google Chrome-Browser Webseiten, die per http ausgeliefert werden, als unsicher an. Hier ein paar Infos und Gedanken zum Thema.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1356],"tags":[406,4328],"class_list":["post-181358","post","type-post","status-publish","format-standard","hentry","category-google-chrome-internet","tag-chrome","tag-sicherheit"],"_links":{"self":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/181358","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/comments?post=181358"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/181358\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/media?parent=181358"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/categories?post=181358"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/tags?post=181358"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}