[aklug] Re: [NUGA] Re: If you are still running SSLv2, you should disable it ASAP

Indeed. Note that a valid point made by the off-post query was that our
mailing list is publicly archived.

Royce

On Wed, Mar 2, 2016 at 11:05 AM, David W. Monroe <david.monroe@ctg.com>
wrote:

> I also agree with you both. Although the email lists here are large, when
> an individual detects an issue, this is by far one of the fastest ways to
> get the info out to the “right people” without it being truly “Public”.
>
>
>
> This is far more discreet than posting on a social media site or public
> website.
>
>
>
> Dave
>
>
>
> David W. Monroe
> Senior Network Administrator
>
>
>
> 4701 Business Park Blvd
> Building J, Suite 36
> Anchorage, AK 99503
>
> Office: 907-261-4700
> Mobile: 907-360-0517
> Fax: 907-261-6520
>
> To request Hardware or software, please use the form, available as a Word
> document, located at *CTG HW-SW Request Form*
> <https://ctgcentral.ctg.com/gmsr/documents/purchasing/f-pur-hardware-software-request.docx>
> *.* For account changes and file server access, please use the form *CTG
> User Access Request Form
> <https://ctgcentral.ctg.com/gmsr/documents/is/fais-user-access-request.doc>*
> located in the same location. For support issues/requests you are welcome
> to and encouraged to contact the CTG Help Desk @ 1-800-544-9071 (from inside
> the CTG office x3556). If they are unable to help you solve the problem,
> they will escalate a Remedy ticket regarding your problem to someone that
> can assist you further. You may also contact the *Help Desk
> <helpdesk@ctg.com?subject=Help%20me%20Please!>* via email. They are
> listed in the CTG Global Address List as "Helpdesk".
>
>
>
>
>
> *From:* nuga-bounce@lib.uaa.alaska.edu [mailto:
> nuga-bounce@lib.uaa.alaska.edu] *On Behalf Of *JP
> *Sent:* Wednesday, March 02, 2016 10:34 AM
> *To:* Royce Williams
> *Cc:* Network Users Group Alaska; aklug@aklug.org
> *Subject:* [NUGA] Re: If you are still running SSLv2, you should disable
> it ASAP
>
>
>
> Royce, I am with you 100%. I appreciate your approach of transparency and
> compiling public info for us to easily peruse. I am kind of happy I dodged
> the bullet on those domains, but I did see a handful of friends on there
> and I know they aren't aware, so I sent them a friendly warning.
>
>
>
> Keep it up!
>
>
>
> Now... if only it were this simple to look at all the IPs with no
> hostnames that my clients have for their VPNs or other services that don't
> really need (or out of laziness don't have) a hostname, I am still in panic
> mode till I get through all of those! So far so good though, I only use
> OpenVPN and TLS.
>
>
>
> Thanks for your help Royce.
>
>
>
> On Wed, Mar 2, 2016 at 10:16 AM kris laubenstein <
> krislaubenstein@gmail.com> wrote:
>
> For what it's worth, I agree with Royce. We all know security through
> obscurity is no security at all. Also, it feels good to not see any of my
> domains on a truly "external" scan!
>
> If you're running IIS, a super easy tool for quick cryptography configs is
> a tool called IIScrypto. Sure, you can do it all easier through CLI, but
> there's something to be said about being able to hand off some security and
> crypto config to the help desk.
>
> https://www.nartac.com/Products/IISCrypto
>
> Kris
>
> On Mar 2, 2016 10:05 AM, "Royce Williams" <royce@tycho.org> wrote:
>
> Of the five off-list responses I've gotten so far, four have been "yikes
> -- thanks, on it!", and one has expressed concern about posting these scan
> results publicly. This last is a fair question, and deserves a public
> answer.
>
> I try to walk the disclosure line responsibly. For example, for the
> Alaskan HTTPS Qualys results that I cache [1], I limit access to Alaskan IP
> space, which mitigates this concern for overall Alaskan SSL/TLS health.
>
> But, in my opinion, SSLv2 is an entirely different animal.
>
> Relying solely on obscurity -- and not upgrading/patching/mitigating -- to
> address issues with SSLv2 (a protocol that has been deprecated *by RFC* for
> five years! [2] ) was never a good idea, and now officially borders on
> negligence. Any downstream clients who have heartburn from a public list
> of SSLv2-exposed hosts need to start asking hard questions from their
> providers -- about why the boxes in question are so insecure, and have been
> exposed to the public Internet for so long.
>
> In this modern era of masscan, Shodan, Qualys SSL Labs, and even good old
> nmap ... anyone can search in a second, or scan in five minutes. And
> Google's Project Zero [3] now automatically discloses major vulnerabilities
> after a hard 90-day timer [4].
>
>
>
> We must take steps to see the world from the attackers' eyes.
>
>
> Royce
>
>
>
> 1. http://www.techsolvency.com/tls/
>
> 2. https://tools.ietf.org/html/rfc6176
>
> 3. https://en.wikipedia.org/wiki/Project_Zero_(Google)
>
> 4. https://code.google.com/p/google-security-research/issues/list?can=1
>
>
>
>
>
> On Tue, Mar 1, 2016 at 9:00 PM, Royce Williams <royce@tycho.org> wrote:
>
> Did a fresh scan against known Alaskan hosts - attached are those that
> still offer SSLv2 and should be adjusted ASAP. Sorted by TLD, then domain,
> then host (so that hosts in the same domain are grouped together).
>
>
>
> Royce
>
> ​
>
>
>
> --
>
>
>
> *JP (Jesse Perry)*
> voice/txt: 907-748-2200
> email: jp@jptechnical.com
> web: http://jptechnical.com
>
> The information transmitted is intended only for the person or entity to
> which
> it is addressed and may contain confidential and/or privileged material.
> Any
> review, retransmission, dissemination or other use of, or taking of any
> action
> in reliance upon, this information by persons or entities other than the
> intended recipient is prohibited. If you are not the intended recipient of
> this
> message, please contact the sender and delete this material from this
> computer.
>

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Wed Mar 2 09:38:55 2016