Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security Encryption Privacy The Internet

WordPress.com Enables HTTPS Encryption For All Websites 86

On Friday, WordPress announced that it is bringing free HTTPS to all -- "million-plus" -- custom domains, essentially ramping up security on every blog and website. The publishing platform says it partnered with Let's Encrypt project to implement HTTPS across such a voluminous number of sites. From the blog: For you, the users, that means you'll see secure encryption automatically deployed on every new site within minutes. We are closing the door to un-encrypted web traffic (HTTP) at every opportunity.
This discussion has been archived. No new comments can be posted.

WordPress.com Enables HTTPS Encryption For All Websites

Comments Filter:
  • by Anonymous Coward

    smart move, monkeys

  • HTTPS real meaning (Score:3, Insightful)

    by fbobraga ( 1612783 ) on Friday April 08, 2016 @02:39PM (#51870295) Homepage
    "Hopefully Talking To People Securely" (sorry by the joke, but it was stronger than me :P)
    • by bluefoxlucid ( 723572 ) on Friday April 08, 2016 @02:56PM (#51870439) Homepage Journal

      The big push for HTTPS is a technological one as far as I can see. Back in the day, you'd buy a separate SSL endpoint to handle the encryption; today, TLS encryption of HTTP causes latency increases of a statistical 5mS at worst (i.e. there's a lot of overlap and it looks like 0, but a lot of math tells us there's 5mS lost on average somewhere in there if you look hard enough), and the CPU toll is about 2% more computational overhead in the most complex part of the key exchange. TLS costs a fraction of a percent of CPU now for the ongoing session.

      In other words: HTTPS is approximately identical to HTTP in terms of cost, and the likelihood that your site dies under load at any given time is roughly equivalent when using either protocol. Suddenly it's a big dialogue.

      • by tepples ( 727027 ) <tepples@gmai3.14159l.com minus pi> on Friday April 08, 2016 @03:25PM (#51870641) Homepage Journal

        Back in the day, you'd buy a separate SSL endpoint to handle the encryption

        Also back in the day, you'd buy a separate IP address for each customer that wants to employ TLS. That became very expensive in the era of IPv4 address exhaustion. This requirement ended on April 8, 2014, when Windows XP reached the end of extended support. Internet Explorer for Windows XP had been the last major web browser not to support Server Name Indication [wikipedia.org], which makes name-based virtual hosting practical for HTTPS and other TLS-based protocols.

        In other words: HTTPS is approximately identical to HTTP in terms of cost

        This is true so long as you either A. have root on your web server or B. have a means of automating installation of renewed certificates. Some shared hosting providers are so far behind on Let's Encrypt implementation that people have become passive-aggressive, making a Ruby script to automatically send an e-mail to the host's support department to get a renewed cert installed [github.com].

        There is another cost: mixed content blocking. A lot of sites rely on external resources not yet available through HTTPS, and web browsers block HTTP resources embedded in an HTTPS page. Sponsors are a big one; not until September 2013 [googleblog.com] did a major ad network become available through HTTPS.

        • This is true so long as you either A. have root on your web server or B. have a means of automating installation of renewed certificates.

          (A) is a matter of service and marketing; (B) is a matter of technology. That it's cheap to do something (i.e. technology) doesn't mean people have done it (else everything would have gone TLS in the mid-2000s, when this privacy dialogue had gotten nice and hot--remember PGP in the 90s?).

        • Yeah, remote HTTP and HTTPS resources embedded on our HTTPS page didn't work any more. This is why I haven't implemented an HTTP forward to HTTPS rule yet, though I do have TLS certs for my websites now.

          Weirdly enough, Google's Calendar and some other things are Iframed HTTPS but work whether embedded in an encrypted page or not. I would love to know how they do that.

          • by tepples ( 727027 )

            Weirdly enough, Google's Calendar and some other things are Iframed HTTPS but work whether embedded in an encrypted page or not. I would love to know how they do that.

            An HTTPS frame inside an HTTP page always works. The reverse does not.

  • by JourneymanMereel ( 191114 ) on Friday April 08, 2016 @02:54PM (#51870419) Homepage Journal

    Sadly this probably means tons of mixed content security errors are about to start happening. Everybody who linked to an image in their blog with the full URL (http://site.com/image.png) will have images that used to load with no problem start throwing up security errors. I had this problem when I got the Let's Encrypt certificate for my blog. Had to go back and change all the images I had loaded in my previous posts to use my new https URLs. Fortunately, I don't post often so there weren't too many...

  • Great all sites that should have been "static" are sent over encrypted channel while WP is still a Swiss cheese.
    • I started converting my older WordPress websites into static websites. My main website used to get 4,000+ script kiddies per day from Russia and Asia. After it became a static website with no PHP or SQL calls, they went somewhere else.
  • I just heard "You're going to be getting a lot of calls from people because Let's Encrypt isn't a CA they trust, and instead of it just being encrypted, people will think it's broken."

  • by Anonymous Coward

    of encrypting 99.99% of blog traffic, when that traffic - the blog posts - is visible to the whole Internet anyway?

    • The more TLS traffic we get flooding the Internet, the less indiscriminate hoovering the spooks will do?

  • HTTP/2 might be the actual main motive for this switch. HTTP/2 is more efficient than HTTP/1 but requires TLS encryption.

    Indeed, wordpress.com [wordpress.com] does offer HTTP/2:

    url="https://www.wordpress.com"
    curl -v --http2 -I -o /dev/null "$url" 2>&1 |grep ALPN
    * ALPN, offering h2
    * ALPN, offering http/1.1
    * ALPN, server accepted to use h2

  • That as a value added service, with per year costs they could add onto low upfront priced hosting and domain packages.

According to the latest official figures, 43% of all statistics are totally worthless.

Working...