

HN now comes with HTTPS? - mike-cardwell
https://news.ycombinator.com/

======
mike-cardwell
The Firefox addon HTTPS Finder just alerted me to the fact that there was an
HTTPS version of the site at <https://news.ycombinator.com/> \- I tried it
out, and it worked. Nice work.

EDIT: Session cookie needs to be set as "secure" and Strict-Transport-Security
should be implemented in order to protect against certain attacks. End users
can just add this HTTPS-Everywhere ruleset:

[https://raw.github.com/mikecardwell/https-
everywhere/73241d1...](https://raw.github.com/mikecardwell/https-
everywhere/73241d145b7bb8f62d9be2f713baafb622501fce/src/chrome/content/rules/YCombinator.xml)

~~~
EGreg
Can you elaborate please? What is this "HTTPS everywhere" and why do we need
it?

~~~
tobylane
Here's a silent Chrome version
[https://chrome.google.com/webstore/detail/flcpelgcagfhfoegek...](https://chrome.google.com/webstore/detail/flcpelgcagfhfoegekianiofphddckof)

~~~
mtogo
Watch out, this extension does _not_ do what HTTPS-Everywhere does! With KB
SSL Enforcer, your browser still hits the HTTP version before being redirected
to the HTTPS version of the site.

------
yahelc
So, now the HN effect will be less measurable, as traffic from HTTPS to HTTP
doesn't pass a referrer.

(This just increases the incentive for sites to use HTTPS Everywhere, so
they're not left out in the dark as to who is sending them traffic.)

------
Joakal
Nifty report of HN's HTTPS:
[https://www.ssllabs.com/ssldb/analyze.html?d=news.ycombinato...](https://www.ssllabs.com/ssldb/analyze.html?d=news.ycombinator.com)
Grade C it seems

~~~
tptacek
These stupid grades kind of drive me nuts, but they really should disable SSL
2.0 and the export ciphers.

~~~
netik
SSLab's grades are not stupid. They monitor how solid the SSL implementation
is and what needs to be corrected to ensure higher security on the site.

Another useful tool is SSLScan, which for Hacker News shows that they are
accepting of a very strange set of HTTPS cipher and MAC configurations.

SSLv2 should be turned off, as well as the majority of 40-bit and 56-bit
ciphers. Their unusual preference of CAMELLIA-256-CBC is pretty amusing to me.

    
    
      Prefered Server Cipher(s):
        SSLv2  168 bits  DES-CBC3-MD5
        SSLv3  256 bits  DHE-RSA-AES256-SHA
        TLSv1  256 bits  DHE-RSA-AES256-SHA
    

Whaaaaat?

~~~
tptacek
Agree to disagree on the grades, and agree to agree on SSLv2 and export
ciphers.

(I have other complaints about the SSLabs grades, but I'm not getting into it
here).

~~~
dfc
Why not? I understand you do not have infinite time but if you get the chance
I would enjoy hearing your thoughts.

------
charlieok
Glad to see this trend. How about using https links in the RSS feeds, so that
anyone coming in from their feedreader gets https by default?

------
st3fan
This is great. It would be even better if HN would use the Strict-Transport-
Security header so that browser remember to prefer https instead of http for
this site.

See [http://blog.sidstamm.com/2010/08/http-strict-transport-
secur...](http://blog.sidstamm.com/2010/08/http-strict-transport-security-
has.html)

~~~
tptacek
If they were taking credit card numbers, STS would be worth the trouble;
otherwise, it's not something I'd recommend going out of your way for.

For non- HTTPS- nerds: STS resolves the problem where your first contact with
a site is via (insecure) HTTP, and a MITM makes all subsequent contacts lie to
you about whether HTTPS is available. Since we've lasted many years without
even _having_ HTTPS, I think we can all just look at the address bar carefully
instead.

~~~
mike-cardwell
That is not the only problem it solves. You can go to
<https://news.ycombinator.com/>, but if you visit any other non-https website
at the same time, somebody can MITM _that_ connection, and inject the
following HTML into it:

    
    
      <img src="http://news.ycombinator.com/">
    

That will cause your browser to do a non-https request against
news.ycombinator.com (unless STS is implemented), which in this particular
case can leak the session cookie, because the session cookie hasn't had the
"secure" flag set on it.

I'd say that it _is_ worth going out of your way for. If you're implementing
HTTPS, it is only slightly more effort to implement STS as well. And it's
definitely worth adding the secure flag to the cookie as well.

~~~
tptacek
Not having the secure flag on a cookie (I didn't look, because I don't care
about SSL on HN) is a vulnerability. STS doesn't totally fix that
vulnerability.

STS: Nice to have. Most installed browsers don't even support it.

Cookie Secure flag: Must have. Every modern browser supports it to some
extent.

You're entitled to your opinion about this stuff, but know that my opinion has
been hardened by many many years doing appsec for financial services
companies. I would _not_ doc a company for not having STS†, unless I was doing
design/best practices review. I would doc _anybody_ for not setting the secure
flag on cookies for an HTTPS site.

† _(ie: if you_ ask _me to doc stuff like STS and Clickjacking)_

~~~
mike-cardwell
Thank you for acknowledging my right to an opinion, although I'm not sure why
it was needed. I don't think your credentials put you in a better position to
comment on this particular matter, but you're still entitled to your opinion
anyway.

It takes very little effort to implement STS, and there are significant
tangible benefits from doing so. For this reason alone, I would recommend that
_all_ HTTPS sites use it. I acknowledge that using the "secure" flag with
cookies provides a bigger benefit though.

~~~
tptacek
Saying "you have a right to your opinion" sounds better than "I'm pretty sure
you're just totally wrong about this", doesn't it? :)

HN doesn't have a framebuster either, but you didn't call them out on that.
The security nerds we work with are far more likely to call us out for not
hyperventilating about clickjacking than about HSTS, which, again, is not
widely supported in the field to begin with.

There are _actual_ apparent problems with HN's HTTPS; it will for instance
happily do SSLv2 with 40 bit RC4. Let's advocate for those fixes first.

~~~
mike-cardwell
It's more passive-aggressive certainly. The SSL config does need tuning, and
frame busters adding. That doesn't make STS any less important.

No modern browser is going to choose such a weak cipher, but because SSLv2 is
enabled, a MITM can force it. The same MITM who can abuse the lack of STS.

~~~
tptacek
The equivalence you're drawing between what a MITM can do with STS and what a
MITM can do with SSLv2 is an objectively false one.

I think you've gone on tilt on this issue, so, feel free to the last word.

~~~
mike-cardwell
I'd prefer if you could educate me on how I'm wrong? I was referring to the
ability of a MITM to attack the initial negotiation with a downgrade attack on
SSLv2. Modern browsers aren't susceptible to this unless I'm mistaken?

All modern browsers are susceptible to the other MITM attack I described
though. Unless the website uses STS.

EDIT: It's worth noting that anybody using IE7+, FF2+, Opera, Chrome or Safari
aren't affected be the weak ciphers, or by the existence of SSLv2, as their
browsers will not negotiate a weak SSL connection. They are _all_ affected by
the lack of STS though.

~~~
tptacek
No, because IE7+, FF2+, Opera, and Safari don't support HSTS. New Firefox
does, and Chrome does.

~~~
mike-cardwell
Good catch. Although, when comparing an issue that affects no modern browser
against an issue which affects all modern browsers, the issue which affects
all modern browsers is perhaps a little more important.

And when there's a solution that is trivial to implement, and can fix the
issue for two existing major modern browsers (probably more to come), it might
not be a completely crazy idea to go ahead and implement it.

P.S. Thank you for graciously gifting me the final word

------
wallflower
Thank you, RTM and PG!!

------
jorde
Nice addition to HN. We also updated Chrome's Readable HN to work with HTTPS
[https://chrome.google.com/webstore/detail/jpnbjaechgbbpokepg...](https://chrome.google.com/webstore/detail/jpnbjaechgbbpokepgmdkhgjfmkmjecn)
and if you would like to contribute <https://github.com/jorde/readable-hn>

------
pieter
For some reason it's now impossible for me to connect over normal http:

    
    
        manila:pieter$ curl -I http://news.ycombinator.com
        curl: (52) Empty reply from server
        manila:pieter$ curl -I https://news.ycombinator.com
        HTTP/1.1 200 OK
        Date: Sun, 21 Aug 2011 15:09:27 GMT
        Content-Type: text/html; charset=utf-8
        Cache-Control: private

~~~
qjz
When a single IP address can support multiple virtual hosts, probing port 443
for an SSL version of a domain is naive and may trigger an intrusion detection
system (IDS). Sure, you may get a response (and even the same content), but
that's no guarantee that _the domain you used_ is configured for SSL on the
server. An IDS may flag the request as a potentially malicious probe and
temporary block the IP address from accessing some resources. This can be
extremely useful for blocking exploit attempts by drive-by bots that request
by IP address alone. Of course, it would be strange to continue to allow
access to the SSL resource as in your example, but maybe there's a reason for
it (server admin has different goals than site admin, for example). Just one
possible explanation. You might regain HTTP access if you stop hitting HTTPS
for a while.

Edit: The CN in the cert is news.ycombinator.com, so it's unlikely my
explanation is the cause (but still could be).

~~~
mike-cardwell
Is it "naive", or is it totally harmless? I've been using HTTPS Finder, which
probes for HTTPS versions of websites for quite a while now, without any
noticeable negative effects. I'm sure sites out their exist which have this
IDS configuration that you describe, but none of the ones I've visited do. As
for the positives, I can't remember how many HTTPS versions of sites that it's
alerted me to, but it's a _lot_

~~~
qjz
It's naive ("let's poke it with a stick and see what happens"), but should be
mostly harmless with a properly configured IDS. You don't want to permanently
blacklist legitimate users, just discourage malicious ones.

Unfortunately, there's no guarantee that an HTTPS site is identical to the
corresponding HTTP site. In most web servers, each one has its own
configuration, so it's best to visit SSL sites only when you've been
explicitly directed to do so.

------
deno
As a side-effect HN has upgraded from HTTP 1.0 to HTTP 1.1.

------
brackin
This is great, thanks PG! Only problem for me is that the theme i'm running
will no longer work but that's okay, i'm sure they'll update.

~~~
davezatch
Not sure what kind of theme you're using, but it broke the Greasemonkey script
Hacker News OnePage for me. If you're using something like greasemonkey or
stylish, you might have to go into the script and tell it to work on https,
since the sites are whitelisted with only http. That should do it.

------
MikeCapone
Is it possible for HN to use Google's SPDY protocol for better performance?

~~~
grinich
Is this even supported by Chrome yet?

~~~
bradly
Yes. Many of Google's own sites like Gmail and Google Maps use SPDY in Chrome.

------
pclark
Why do people want https on Hacker News?

~~~
tlrobinson
IMHO any site that has a login form should use HTTPS.

~~~
jmatt
Yep. For further explanation:

<http://codebutler.com/firesheep>

------
k33n
Seems like overkill to me.

~~~
dan_manges
I was at a conference recently and saw somebody start Firesheep -- HN profiles
showed up. So the choices were: use HN on open wifi but risk having your
session stolen, don't use HN, or connect to a VPN. The VPN is probably the
smartest thing to do on an open wifi network, but it's nice to know that HN is
now safe to use without it.

~~~
iuguy
If you're going to a conference and you're using wifi there, please use a VPN.
If you're going to a coffee shop and using wifi, if at all possible use a VPN.

By not using a VPN you're leaving yourself open to all manner of attacks (take
for example the recent iOS SSL Cert validation issues as an example, but also
consider the fact that an attacker could inject malicious content to attack
your system over any HTTP traffic - or invalid HTTPS traffic if you make the
connection).

At the very least you should use an SSH tunnel or some form of transport to
protect all of your outbound traffic when in a hostile environment.

