[aklug] Re: SSL "health" in Alaska (was: ACS Google Gateway)

From: Royce Williams <royce@tycho.org>
Date: Sun Oct 13 2013 - 05:48:39 AKDT

Greg, for what it's worth, neither of those domains do much of
anything other than redirect to other sites, most of which aren't
doing SSL. Ditto for attalascom.com, as Arthur pointed out
off-thread.

That being said, mymail.acsalaska.net doesn't have SSL, but should.
As it was explained to me, implementing the latter would be
non-trivial, but would have been worth the effort, IMO (though may be
moot now, as they're moving to Google-hosted mail services).

Is there a case where having local-to-the-ISP caching servers would
provide Google (and by extension, the Three Letter Agencies)
information about your connection or traffic that it couldn't get by
demanding info from Google (which they can do) or demanding info from
ACS (which they can do)?

Or, since the only thing that Google caches do is cache Google
content, perhaps you're suggesting that there's correlation info
available when using Google caches instead of Google's products
directly? If so, I'm not sure how that would work; could you provide
a little more detail?

Royce

On Sat, Oct 12, 2013 at 10:47 PM, Greg Schmitz <greg@amipa.org> wrote:
>
> Royce and Tom,
>
> Thanks for your insights. Last time I checked ACS had not implemented SSL,
> at least for residential users. My concern with the ACS affiliation with
> Google is that, as an ACS residential customer who connects to The Internet
> via ACS, is that Google might have access to unique identifiers that
> circumvent any attempts to keep what I look at, do on The Internet (FTP,
> Torrent, etc), or send via email private using measures at home will fail.
> It's not very complicated and like I said - you don't get something for
> nothing. Those Google boxes that sit inside the ACS network come at a
> price? FWIW https://www.ssllabs.com/ssltest/analyze.html?d=acsalaska.net
> yields nothing and https://www.ssllabs.com/ssltest/analyze.html?d=gci.net
> gets an "F" from SSL Lab????
>
> --greg
>
>
>
> On 10/12/2013 01:43 PM, Royce Williams wrote:
>
> On Sat, Oct 12, 2013 at 1:03 PM, Royce Williams <royce@tycho.org> wrote:
>> On Sat, Oct 12, 2013 at 10:02 AM, Tom Simes <simestd@netexpress.com>
>> wrote:
>>
>> [snip]
>>
>>> The take away is if privacy is important, you need to be using perfect
>>> forward secrecy and the best current implementation is via
>>> Diffie-Hellman. OpenSSL can implement this now, but it's not default.
>>
>> What Tom said. Here's a great way to check the health and de-facto
>> negotiated browser cipher sets for your web OpenSSL setup:
>>
>> https://www.ssllabs.com/ssltest/
>>
>> Be sure to check the "Do not show the results on the boards" checkbox
>> if you don't want your test to show up in the lists.
>
> I thought I'd elaborate a bit here.
>
> First, the gold standard (but don't try this at home; Google has in-house
> customization of OpenSSL to get this level of security:
>
> A:
> https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com&s=173.194.46.0
>
> And some results of local interest (I flipped through the State's list of
> top employers and picked some with Alaska-specific web servers:
>
> A: https://www.ssllabs.com/ssltest/analyze.html?d=my.alaska.gov
> A: https://www.ssllabs.com/ssltest/analyze.html?d=alaskaair.com
> F: https://www.ssllabs.com/ssltest/analyze.html?d=anthc.org
> A:
> https://www.ssllabs.com/ssltest/analyze.html?d=www.alaskausa.org&s=208.69.197.106
> A: https://www.ssllabs.com/ssltest/analyze.html?d=alpca.org ;-)
> F: https://www.ssllabs.com/ssltest/analyze.html?d=attalascom.com
> B: https://www.ssllabs.com/ssltest/analyze.html?d=corp.att.com
> A: https://www.ssllabs.com/ssltest/analyze.html?d=cu1.org
> B: https://www.ssllabs.com/ssltest/analyze.html?d=fnbalaska.com
> A: https://www.ssllabs.com/ssltest/analyze.html?d=mtasolutions.com
> F: https://www.ssllabs.com/ssltest/analyze.html?d=muni.org
> A: https://www.ssllabs.com/ssltest/analyze.html?d=northrim.com
> A: https://www.ssllabs.com/ssltest/analyze.html?d=premera.com
> A: https://www.ssllabs.com/ssltest/analyze.html?d=searhc.org
> F: https://www.ssllabs.com/ssltest/analyze.html?d=southcentralfoundation.com
> F: https://www.ssllabs.com/ssltest/analyze.html?d=csiweb.thealaskaclub.com
>
> Things to look for:
>
> - You get an automatic F if:
> - You support insecure renegotiaton.
> - You support SSLv2, which is permaborked.
>
> - Whether any weak cipher suites or protocols are enabled.
>
> - Handshake simulation, especially if any fail, or whether or not "FS" or
> "No FS" is listed after each item.
>
> - Servers may enable RC4 in order to mitigate BEAST, so you'll often see
> them mutually exclusive.
>
>
> If you're not running OpenSSL 1.0.1 (maybe 1.0.1e?), you should be. If your
> OS has multiple dependencies on OpenSSL, upgrading it in place can be
> painful, and you're better off installing a local instance (/usr/local/ or
> something) and recompiling Apache and kin to use it instead. Or upgrade
> your OS to a version that includes OpenSSL 1.0.1e.
>
> More info on fixing any and all of the above:
>
> https://www.ssllabs.com/projects/best-practices/index.html
>
> Royce
>
>
>
> --
>
> Greg Schmitz
> Alaska Moving Image Preservation Association (AMIPA)
> Anchorage, Alaska
>
> v: 907.786.4983
> f: 907.786.1834
> e: greg at amipa dot org
>
> The Alaska Moving Image Preservation Association is a 501(c)(3) non-profit
> dedicated to media preservation and education to ensure long-term access to
> Alaska’s moving image heritage.
>
> www.amipa.org
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Sun Oct 13 05:49:23 2013

This archive was generated by hypermail 2.1.8 : Sun Oct 13 2013 - 05:49:23 AKDT