InCommon Technical Discussions

[Nick Roy <>]

I'll point out that the SSL test is a *recommended* piece but *not
required* in the current specification of Baseline Expectations.

To restate what I've heard so far:

Logo URL:

- results in a 200 via HTTP GET
- is a PNG with a transparent background / alpha channel (because JPG
does not support transparency)
- is 80w x 20h

SSL for endpoints:

- subject to InCommon operations' running of SSL scans (exact nature to
be determined by operations)
- operations may save and act on information about the quality of SSL at
its discretion

(no minimum grade or other requirement related to SSL)

errorURL:

- results in a 200 via HTTP GET, other results cause a warning but not a
full failure of the baseline tests
(do we need to say something about 302 and maximum depth to chase
referrals before lack of a 200 causes failure?)

How does that look?

Thank you,

Nick

On 11/9/17 8:47 AM, Chris Phillips wrote:
> Great dialogue on this.
>
> Maybe it would be better to define what’s not acceptable regarding a grade 
> and what’s a reasonable duration to remediate.
>
> Highest grade (A+) preferred but no lower than C on ssllabs and no longer 
> than say X days below this band of acceptance.
>
> This gives latitude to maneuver when the tools change underneath one’s feet 
> and dependencies to catch up. 
> Jacob’s example is great in this regard. If his group didn’t care about it 
> (or know to test that way) then how would he have pushed for the change to 
> get back into compliance and hence pressured the vendor to step up?
>
> That said, things like Poodle SSLv3 and other future events we know will 
> happen will change ranking from A+ to F overnight. Using the idea of X days 
> to come into compliance allows us to respond commensurate with the risk.  
> It also allows us to simply be users of the tool which is not our core 
> mission – we just want the output to inform our decisions.
>
>
> C
>
> On 2017-11-09, 9:53 AM, "Farmer, Jacob" 
> <
>  on behalf of 
> >
>  wrote:
>
>     Nick,
>     
>     I like the Qualys SSL scanner and we use it often. Given my history, 
> though, I 
>     am reluctant to rely on it for this kind of thing. A real-world story 
> from the 
>     last few years: Qualys made a change to the scanner which caused sites 
> we 
>     manage that were in the A range to fall into the B+ range. I don't 
> recall all 
>     of the details about why; I think it had to do with cipher suites. Our 
> load 
>     balancer -- a widely deployed product on its current version -- could 
> not be 
>     adjusted to bring it back up to A. There was something in the 
> configuration 
>     that Qualys simply didn't like and there was no way to fix it until a 
> vendor 
>     patch shipped.
>     
>     I'm glad that we took the time to get it figured out, but I also don't 
> think 
>     that the quality of SSL was meaningfully degraded in the interim.
>     
>     I support the idea of defining "good TLS" but I am reluctant to rely on 
> this 
>     scanner to define it.
>     
>     Jacob
>     
>     -----Original Message-----
>     From: 
> 
>  
>     
> [mailto:]
>  On Behalf Of Nick Roy
>     Sent: Wednesday, November 8, 2017 4:59 PM
>     To: Cantor, Scott 
> <>;
>  
> 
>     Subject: Re: [InC-Technical] InCommon Baseline Expectations Metadata 
>     Requirements
>     
>     
>     
>     On 11/8/17 1:58 PM, Cantor, Scott wrote:
>     >> RECOMMENDED:
>     >>
>     >>    SSL certificates on endpoints are valid
>     > That seems like a slippery slope: valid re: dates? Specific CAs? Key 
> sizes? 
>     > What about ciphers, or use of TLS 1.0, etc.?
>     >
>     > Requiring a logo is, I think, underspecified, we should mandate 
> specific 
>     > size(s).
>     >
>     > I'd like to see errorURL be required with guidance around what should 
> be 
>     > behind it.
>     
>     We think errorURL should be included as well, but since it was not part 
> of the 
>     'required' elements that AAC specified (AAC assumed errorURL was part 
> of the 
>     mdui: information, and it is not) that means this would have to go back 
> to ACC 
>     to make errorURL a separate required element.
>     
>     Agree re: specific requirements for SSL and logo.
>     
>     Here is my proposed requirement for SSL for endpoints (since it's 
> recommended 
>     but not required):
>     
>     - Achieve a grade of A on the Qualys SSL scanner [1]
>     
>     And for HTTPS Logo URL:
>     
>     - Must result in an HTTP 200 in response to a GET request
>     - Image must be either a PNG or JPG
>     - Image must be 80 pixels in width by 60 in height
>     
>     [1] https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide
>     
>     Let me know if you think this is something that would better be 
> discussed in 
>     detail by the Ops Advisory Group or in some other venue.
>     
>     Thank you,
>     
>     Nick
>     
>     >
>     > -- Scott
>     >
>     >
>     
>