5 ms·

Ok, why shouldn't we use HTTPS? To me it seems silly that the vast majority of traffic isn't atall encrypted.

by 46Bit 15y ago

icebraining 15y ago
Well, HTTPS adds latency due to its handshake, and of course it uses more CPU, especially on the server (unless a dedicated SSL offloaders is used).
- 46Bit 15y ago
  And yet on the flipside, it should prevent interception of login credentials or page-content filtering.
  - icebraining 15y ago
    > it should prevent interception of login credentials That was already possible using HN's OpenID support and a secure provider.
    - mike-cardwell 15y ago
      OpenID doesn't prevent session hijacking though does it? It would just prevent the credentials being stolen.
  - 46Bit 15y ago
    > That was already possible using HN's OpenID support and a secure provider. Not actually sure what your point is here.
    - icebraining 15y ago
      Using OpenID (with a secure provider) to login to HN prevents the stealing of login credentials and was possible even without HN supporting HTTPS. I don't see what's strange about this. By the way, I'm not claiming that enabling HTTPS is wrong, I'm giving potential disadvantages. It's the website admins' job to weight those against the advantages and decide whether it's the right thing to do or not.
      - bensummers 15y ago
        OpenID may prevent stealing login credentials, but it doesn't prevent stealing the cookie which identifies your session.
        wisty 15y ago
        Also, if you can hijack the http, you can link to a phishing site which prompts users for their OpenID provider (typically their google account) credentials. Maybe they would notice that the domain name of the phishing site (say googleopenid.com, which is available) is fishy ... https gives you more than just encryption.
      - 46Bit 15y ago
        I meant why the fact there was a way to do it already actually related to the debate overmuch. This protects people who just use a bog-standard HN account, and further secures all users when actually on the site regardless of login method.
- dermatthias 15y ago
  On the server side, it is ycombinator's decision if they can handle the additional cpu cycles. i believe they can, or else they wouldn't have enabled it. on the client side, I don't think you can really feel the latency. is measurable, of course, but i don't think you can feel it.
  - icebraining 15y ago
    >on the client side, I don't think you can really feel the latency. is measurable, of course, but i don't think you can feel it. That doesn't seem to be the general opinion here: http://news.ycombinator.com/item?id=2565694 http://news.ycombinator.com/item?id=2565694
    - Tharkun 15y ago
      And high(er) latency on HN would be a problem because ... ? It's such a highly interactive website? There are billions of high quality images to be loaded? Hundreds of ajax calls going back and forth every second? Right.
  - robfig 15y ago
    You can't feel the latency? It adds half a second or more to initial page load times. For doing any sort of marketing where potential customers are arriving at your landing page, that's huge.
    - 46Bit 15y ago
      Not necessarily so noticable. I've been running my personal site with https and the effect is fairly minor on the whole in terms of load times. Not zero, but low enough that your average user on the other side of the Atlantic wouldn't notice much of a difference to normal. Admittedly this is a poor comparison vs a huge site, but then you'll probably find the server processing time is your greater foe.
    - dermatthias 15y ago
      I was refering to my own feeling when loading HN, a (in comparison) very simple website. I am sorry if it sounded like I was talking about any website in general. That is not the case.
- jws 15y ago
  Rules of thumb for 2011: • If you are generating your content in a dynamic creation system, the encryption overhead of SSL is not going to matter. • SSL initial session latency is highly variable based on packet round trip time of the user. Some people will be irritated, other's can't tell the difference.† ␄ † I suppose there is room in the world for a CDN-like entity that places anycasted SSL entry points in strategic locations (or topology sensitive DNS lookups), then uses a zero-turnaround at startup encryption protocol back to the "real" servers. (Say, HTTP over a VPN or something more clever, after all you are the client and the server, life is easy). You'd even beat straight HTTP since by keeping alive the HTTP link to the real servers you'd save the TCP SYN turnaround. 👍 ‡ Unrelated: The unicode committee has lost their mind. OS X Lion users will be seeing a flesh colored thumbs up symbol at the end of the previous paragraph. I suppose now that PILE_OF_POO and NAIL_POLISH are taken care of the committee will add everyone's avatars from all systems.
  - cpeterso 15y ago
    I thought you were joking about PILE_OF_POO and NAIL_POLISH until: http://www.fileformat.info/info/unicode/char/1f4a9/index.htm http://www.fileformat.info/info/unicode/char/1f4a9/index.htm http://www.fileformat.info/info/unicode/char/1f485/index.htm http://www.fileformat.info/info/unicode/char/1f485/index.htm WHY?!
    - biot 15y ago
      I assume you've seen this? http://💩.la http://💩.la http://www.panic.com/blog/2011/07/the-worlds-first-emoji-domain/ http://www.panic.com/blog/2011/07/the-worlds-first-emoji-dom...
  - xentronium 15y ago
    > OS X Lion users will be seeing a flesh colored thumbs up symbol at the end of the previous paragraph All I see is EOT symbol
pbreit 15y ago
It hides the referer which is unfortunate. Maybe an option only to login, register, etc via HTTPS?
- mike-cardwell 15y ago
  Many people, myself included, would see that as a good thing. Not an "unfortunate" thing. Limiting HTTPS to logins only allows session hijacking. Session hijacking is a serious problem.

Ok, why shouldn't we use HTTPS? To me it seems silly that the vast majority of traffic isn't atall encrypted.

by 46Bit 15y ago

Ok, why shouldn't we use HTTPS? To me it seems silly that the vast majority of traffic isn't atall encrypted.

Well, HTTPS adds latency due to its handshake, and of course it uses more CPU, especially on the server (unless a dedicated SSL offloaders is used).

46Bit 15y ago
And yet on the flipside, it should prevent interception of login credentials or page-content filtering.
- icebraining 15y ago
  > it should prevent interception of login credentials That was already possible using HN's OpenID support and a secure provider.
  - mike-cardwell 15y ago
    OpenID doesn't prevent session hijacking though does it? It would just prevent the credentials being stolen.
- 46Bit 15y ago
  > That was already possible using HN's OpenID support and a secure provider. Not actually sure what your point is here.
  - icebraining 15y ago
    Using OpenID (with a secure provider) to login to HN prevents the stealing of login credentials and was possible even without HN supporting HTTPS. I don't see what's strange about this. By the way, I'm not claiming that enabling HTTPS is wrong, I'm giving potential disadvantages. It's the website admins' job to weight those against the advantages and decide whether it's the right thing to do or not.
    - bensummers 15y ago
      OpenID may prevent stealing login credentials, but it doesn't prevent stealing the cookie which identifies your session.
      - wisty 15y ago
        Also, if you can hijack the http, you can link to a phishing site which prompts users for their OpenID provider (typically their google account) credentials. Maybe they would notice that the domain name of the phishing site (say googleopenid.com, which is available) is fishy ... https gives you more than just encryption.
    - 46Bit 15y ago
      I meant why the fact there was a way to do it already actually related to the debate overmuch. This protects people who just use a bog-standard HN account, and further secures all users when actually on the site regardless of login method.
dermatthias 15y ago
On the server side, it is ycombinator's decision if they can handle the additional cpu cycles. i believe they can, or else they wouldn't have enabled it. on the client side, I don't think you can really feel the latency. is measurable, of course, but i don't think you can feel it.
- icebraining 15y ago
  >on the client side, I don't think you can really feel the latency. is measurable, of course, but i don't think you can feel it. That doesn't seem to be the general opinion here: http://news.ycombinator.com/item?id=2565694 http://news.ycombinator.com/item?id=2565694
  - Tharkun 15y ago
    And high(er) latency on HN would be a problem because ... ? It's such a highly interactive website? There are billions of high quality images to be loaded? Hundreds of ajax calls going back and forth every second? Right.
- robfig 15y ago
  You can't feel the latency? It adds half a second or more to initial page load times. For doing any sort of marketing where potential customers are arriving at your landing page, that's huge.
  - 46Bit 15y ago
    Not necessarily so noticable. I've been running my personal site with https and the effect is fairly minor on the whole in terms of load times. Not zero, but low enough that your average user on the other side of the Atlantic wouldn't notice much of a difference to normal. Admittedly this is a poor comparison vs a huge site, but then you'll probably find the server processing time is your greater foe.
  - dermatthias 15y ago
    I was refering to my own feeling when loading HN, a (in comparison) very simple website. I am sorry if it sounded like I was talking about any website in general. That is not the case.
jws 15y ago
Rules of thumb for 2011: • If you are generating your content in a dynamic creation system, the encryption overhead of SSL is not going to matter. • SSL initial session latency is highly variable based on packet round trip time of the user. Some people will be irritated, other's can't tell the difference.† ␄ † I suppose there is room in the world for a CDN-like entity that places anycasted SSL entry points in strategic locations (or topology sensitive DNS lookups), then uses a zero-turnaround at startup encryption protocol back to the "real" servers. (Say, HTTP over a VPN or something more clever, after all you are the client and the server, life is easy). You'd even beat straight HTTP since by keeping alive the HTTP link to the real servers you'd save the TCP SYN turnaround. 👍 ‡ Unrelated: The unicode committee has lost their mind. OS X Lion users will be seeing a flesh colored thumbs up symbol at the end of the previous paragraph. I suppose now that PILE_OF_POO and NAIL_POLISH are taken care of the committee will add everyone's avatars from all systems.
- cpeterso 15y ago
  I thought you were joking about PILE_OF_POO and NAIL_POLISH until: http://www.fileformat.info/info/unicode/char/1f4a9/index.htm http://www.fileformat.info/info/unicode/char/1f4a9/index.htm http://www.fileformat.info/info/unicode/char/1f485/index.htm http://www.fileformat.info/info/unicode/char/1f485/index.htm WHY?!
  - biot 15y ago
    I assume you've seen this? http://💩.la http://💩.la http://www.panic.com/blog/2011/07/the-worlds-first-emoji-domain/ http://www.panic.com/blog/2011/07/the-worlds-first-emoji-dom...
- xentronium 15y ago
  > OS X Lion users will be seeing a flesh colored thumbs up symbol at the end of the previous paragraph All I see is EOT symbol

pbreit 15y ago

It hides the referer which is unfortunate. Maybe an option only to login, register, etc via HTTPS?

mike-cardwell 15y ago
Many people, myself included, would see that as a good thing. Not an "unfortunate" thing. Limiting HTTPS to logins only allows session hijacking. Session hijacking is a serious problem.