[External] jetty

[Ian Young]

> On 2021-03-18, at 14:45, Domingues, Em <michael-domingues at uiowa.edu> wrote:
> 
> The context here is an ill-advised policy interpretation by InCommon that all IDP and SP operators (in order to achieve "current and community-trusted transport layer encryption") will need to hit an "A" when automatically scanned by Qualys SSL labs in order to meet baseline expectations.

I don't know all of the thinking behind that policy, and I'm fortunate not to have to deal with "the real world" in my deployments, but I've personally mostly regarded the higher Qualys/SSLLabs scores (particularly A and A+) as something to aspire to rather than something useful as a baseline requirement. They can be hard to reach, depending on the technology you are deploying, and they are also moving targets, intentionally. Every time they ratchet up the requirements, people will be left behind, potentially for a long time. Getting to B and staying there is much easier.

Or at least that used to be the case, it has been a bit more stable in the last couple of years.

TL;DR: A+ and A are Aspirational, B is Basically Good Enough; improve when possible and C is Crikey! Fix this!


> Support for TLS 1.0 or 1.1 automatically cap your score to a "B".

This is probably the relevant chart: https://caniuse.com/tls1-2 <https://caniuse.com/tls1-2>

If you want better than B, that implies that you're giving up 1.6% of browser clients (worldwide, of all types). Interestingly, that seems to be only 0.23% of mobile browsers, it's the desktop ones from 2013 and earlier that cause the problem. Of course numbers like that are only meaningful if you know whether their sample is representative of your clients.

If you happen to be stuck with supporting the back channel, you may also need to worry about SPs running old versions of OSs that shipped with ancient OpenSSL versions, etc. (Scott's example of SPs on RHEL 5 is the sort of thing I mean.)

Or maybe you don't have to worry about those, because AFAIR Qualys still don't have an API that allows testing of non-443 endpoints so I don't know if InCommon are proposing to probe those. I use the DrWetter thing for that.

    docker run --rm -ti  drwetter/testssl.sh whatever:8443

Cheers,

    -- Ian




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210318/0bd9fa0a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3883 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20210318/0bd9fa0a/attachment.p7s>