Entries tagged as rss
blog bblog blogdieb cacert duden etymologie feed fun geschlecht hackergotchi hacking harvester karlsruhe kubik lawblog planet recht rechtsanwalt s9y security serendipity simplesharingextensions sprache tippfehler udovetter web20 webmontag webpage websecurity xss browser ajax certificate clickjacking content-security-policy cryptography csp dell edellroot encryption firefox html https javascript khtml konqueror maninthemiddle microsoft php sni ssl superfish tls vulnerability webcore aead aes aok apache berserk bleichenbacher braunschweig bsideshn ca ccc certificates cfb chrome cms datenschutz easterhegg email gajim gnupg gpg hannover jabber joomla key letsencrypt nginx nss ocsp ocspstapling openssl otr owncloud pgp poodle privacy revocation schlüssel sha1 sha2 talk update verschlüsselung x509 xmpp adguard android antivirus breach cloudflare cookies crime crypto csrf facebook freak hash heist http kaspersky komodia mitm netfiltersdk privdog protocolfilters samesite sha256 time transvalid updates web windowsxp creativecommons earth fdl license mars openstreetmap python stadtmitte 0days 27c3 addresssanitizer adobe afra aiglx algorithm altushost antivir apt asan auskunftsanspruch axfr azure badkeys barcamp bash berlin bias bigbluebutton bodensee botnetz bsi bufferoverflow bugbounty bundesdatenschutzgesetz bundestrojaner bundesverfassungsgericht busby bypass c cbc cccamp11 cellular chcounter chromium clamav clang cmi code compiz conflictofinterest cookie crash cve darmstadt deb debian deolalikar diffiehellman dingens diploma diplomarbeit distributions dns domain drupal eff english eplus fedora fileexfiltration firewall fortigate fortinet forwardsecrecy freesoftware freewvs frequency fsfe ftp fuzzing gallery gcc gentoo ghost gimp git glibc gnutls gobi google gsm gsoc gstreamer hackerone heartbleed helma infoleak informationdisclosure internetscan ircbot itsecurity jodconverter keyexchange leak lessig libreoffice linux luckythirteen malware mantis math md5 memorysafety mephisto milleniumproblems mobilephones modulobias moodle mozilla mpaa mplayer mrmcd mrmcd100b mrmcd101b multimedia mysql napster nessus newspaper nist ntp ntpd observatory onlinedurchsuchung openbsc openbts openid openidconnect openleaks openpgp openvas osmocombb packagemanagement padding panda papierlos password passwordalert passwort passwörter pdo phishing pnp privatekey provablesecurity pss rand random rc2 redhat rhein rpm rsa rsapss salinecourier science server session sha512 shellbot shellshock sicherheit signatures slides smime snallygaster sniffing spam sqlinjection squirrelmail sso staatsanwaltschaft stacktrace study stuttgart subdomain sunras support taz thesis tlsdate toendacms überwachung ubuntu unicef unicode useafterfree userdir utf-8 virus vlc vortrag vulnerabilities webapps wiesbaden windows wiretapping wordpress xgl xine xsa zerodays zugangsdaten zzuf calendar cccamp cccamp15 certificateauthority ipv6 libressl openbsd symantec
Friday, June 6. 2014
Enabling encryption by default and using HTTPS only
I recently switched my personal web page and my blog to deliver content exclusively encrypted via HTTPS. I want to take this opportunity to give some facts about enabling TLS encryption by default and problems you may face.First of all the non-problems: Enabling HTTPS by default is almost never a significant performance problem. If people tell me that they can not possibly enable HTTPS due to performance reasons the first thing I ask is if they believe this or if they have real benchmark data showing this. If you don't believe me on that, I can quote Adam Langley from Google here: "In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead."
Enabling HTTPS may cause a number of compatibility issues you may not instantly think about. First of all, we know that IPs in the IPv4 space are limited and expensive these days, so many people probably can't afford having a distinct IP for their web page. The solution to that is a TLS extension called SNI (Server Name Indication) which allows to have different certificates for different domain names on the same IP. It works in all major browsers and has been working for quite some time. The only major browser you'll face these days that doesn't support SNI is the Android 2.x browser.
There are some subtle issues with SNI. One is that browsers have fallback modes if they cannot connect via TLS and that may lead to a connection downgrade to SSLv3. And that ancient protocol doesn't support extensions and thus no SNI. So you may have irregular certificate errors if you are on a bad connection. A solution to that on the server side is to just disable SSLv3. It will make SNI much more reliable.
I don't really have a clear picture how many browsers will fail with SNI. There are probably a number of embedded devices out there like smart TVs with browsers or things alike that have problems. If you have any experiences feel free to post them in the comments.
The first issue I only noticed after I switched to HTTPS: I had an application called RSS Graffiti set up to automatically post all articles I write to a facebook fan page. After changing to HTTPS only it silently stopped working. Re-adding my feed didn't work. I now found a similar service called dlvr.it that I now use to post my RSS feed to facebook. I can only assume that this is a glimpse of a much bigger problem: There are probably tons of applications and online services out there not prepared for an encrypted Internet. If we want more people to deploy encryption by default we need to find these issues, document them and hopefully put enough pressure on their developers to fix them.
Another yet unfixed issue is the Yandex Bot. Yandex is a search engine and although you may never have heard of it it's probably one of the few companies in this area that can claim to be a serious competitor to Google. The reason you may not know it is that it's mostly operating in Russian language. Depending on who your page visitors are this may matter more or less.
The Yandex Bot speaks SSL but according to the Qualys SSL test it only supports the ancient SSLv3. So you have a choice between three possibilities: Don't enable HTTPS by default, enable HTTPS with a shitty configuration supporting ancient technology that will cause trouble for SNI or enable HTTPS with a sane configuration and get no traffic from the leading Russian search engine. None of them sounds very good to me.
Another issue is third party content. For security reasons today's browsers block all active HTTP content (CSS, JavaScript etc.) on HTTPS webpages. This isn't much of a problem for me, but it's a problem for webpages that rely on advertising because from what I hear most advertisement providers don't support HTTPS yet (Google being a laudable exception here). This is the main reason you won't see many news webpages enforcing HTTPS. However, I still have passive third party HTTP content on my blog. That's why you'll probably see a yellow warning sign in front of the URL in some browsers.