| 1 |
On Fri, 27 Mar 2015 19:18:24 +0000 |
| 2 |
"Robin H. Johnson" <robbat2@g.o> wrote: |
| 3 |
|
| 4 |
> > * Some with logins are mixed http/login-via-https, which makes them |
| 5 |
> > vulnerable to ssl-stripping-attacks (e.g. wiki.gentoo.org) |
| 6 |
> Are you sure about this? Everything on wiki should always redirect to |
| 7 |
> SSL very early. |
| 8 |
|
| 9 |
Sure about what? |
| 10 |
When I call the wiki page I currently get: |
| 11 |
http://wiki.gentoo.org/wiki/Main_Page |
| 12 |
|
| 13 |
Clicking on login will redirect to https, but at that point an attacker |
| 14 |
is already able to change this link. |
| 15 |
|
| 16 |
> Enabled for the following sites now (copied from cfengine commit): |
| 17 |
|
| 18 |
Great. (However I don't see that yet live - server restart needed or is |
| 19 |
there some deployment process that has to happen first?) |
| 20 |
|
| 21 |
> > * Make sure all use modern HTTPS features, including: |
| 22 |
> > * OCSP Stapling |
| 23 |
> SSLUseStapling is Apache 2.3+ only, and that isn't stable yet. |
| 24 |
|
| 25 |
That's unfortunate, apache 2.2 is pretty outdated when it |
| 26 |
comes to tls security. |
| 27 |
|
| 28 |
> > * A secure collection of cipher suites |
| 29 |
> What's wrong with our present Ciphers? |
| 30 |
|
| 31 |
Haven't checked them in detail, looks mostly fine. One issue: DH |
| 32 |
ciphers with a small modulus (1024 bit). But that's unfixable within |
| 33 |
apache 2.2, so same as above. |
| 34 |
|
| 35 |
> > (On the long term I think it would also be good to have downloads |
| 36 |
> > over https, but I'm aware that this is more difficult as it |
| 37 |
> > involves mirror operators that are not under direct control of |
| 38 |
> > gentoo infrastructure.) |
| 39 |
> This is why we published signatures on as much as we can. |
| 40 |
|
| 41 |
Yes, signatures are fine, but realistically they require manual |
| 42 |
intervention and not everyone will do that. Defaulting to https is a |
| 43 |
very usable way to make malicious downloads less likely. Signatures |
| 44 |
should stay as an additional protection measure. |
| 45 |
|
| 46 |
> Users behind firewalls that block HTTPS are now going to be blocked |
| 47 |
> from Gentoo services. |
| 48 |
> |
| 49 |
> Last time we proposed going HTTPS-by-default, there was complaint |
| 50 |
> from users that were going to be locked out. |
| 51 |
|
| 52 |
I would be very surprised if this is an issue any more. |
| 53 |
|
| 54 |
These days pretty much all big players use https only (google, |
| 55 |
facebook, twitter, github, ...). You can't really use the |
| 56 |
mainstream internet if your firewall blocks https. |
| 57 |
|
| 58 |
> We're still limited when it comes to services that need wildcards for |
| 59 |
> the service. We have one such presently, and I hope we don't get more: |
| 60 |
> Bugzilla, for attachments. (which are served at a different hostname |
| 61 |
> that can't access your base bugzilla cookies even the attachment |
| 62 |
> contains javascript that runs). |
| 63 |
|
| 64 |
I have hopes that Let's encrypt will also allow free wildcards, but |
| 65 |
that seems to be undecided yet. |
| 66 |
But wildcards aren't super-expensive. One can e.g. get a validation by |
| 67 |
startssl for an unlimited number of wildcards for a year, I don't |
| 68 |
remember the exact price but it was in the 100-200$ range. |
| 69 |
|
| 70 |
cu, |
| 71 |
-- |
| 72 |
Hanno Böck |
| 73 |
http://hboeck.de/ |
| 74 |
|
| 75 |
mail/jabber: hanno@××××××.de |
| 76 |
GPG: BBB51E42 |
Archives