Discussion of requirements 9.1.1-3 (from #738)

[tghosth]

This issue continues a discussion from the closed PR #738 with @csfreak92

These requirements state:

9.1.1 | Verify that secured TLS is used for all client connectivity, and does not fall back to insecure or unencrypted protocols
9.1.2 | Verify using online or up to date TLS testing tools that only strong algorithms, ciphers, and protocols are enabled, with the strongest algorithms and ciphers set as preferred.
9.1.3 | Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher suite.

I still believe these requirements should be considered separately but having read them more carefully, I think they also need to be clearer.

[tghosth]

See #771 where I have made some changes to try and make them clearer. @csfreak92 what do you think?

[jmanico]

9.1.1 looks like it needs to be split, one that says use tls everywhere and a second that says Basically disable old protocols 9.1.2 says use tools to verify new tls config is used 9.1.3 repeats not to use old protocols Yes this is really messy but should be easy to clean up Aloha, -- Jim Manico @manicode Secure Coding Education +1 (808) 652-3805

…

> On May 18, 2020, at 3:44 PM, Josh Grossman ***@***.***> wrote:  This issue continues a discussion from the closed PR #738 with @csfreak92 These requirements state: 9.1.1 | Verify that secured TLS is used for all client connectivity, and does not fall back to insecure or unencrypted protocols 9.1.2 | Verify using online or up to date TLS testing tools that only strong algorithms, ciphers, and protocols are enabled, with the strongest algorithms and ciphers set as preferred. 9.1.3 | Verify that old versions of SSL and TLS protocols, algorithms, ciphers, and configuration are disabled, such as SSLv2, SSLv3, or TLS 1.0 and TLS 1.1. The latest version of TLS should be the preferred cipher suite. I still believe these requirements should be considered separately but having read them more carefully, I think they also need to be clearer. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[tghosth]

@jmanico did you look at my propsed changes from #771? See also below:

#	Description	L1	L2	L3	CWE
9.1.1	Verify that TLS is used for all client connectivity, and does not fall back to insecure or unencrypted communications. (C8)	✓	✓	✓	319
9.1.2	Verify using online or up to date TLS testing tools that only strong cipher suites are enabled, with the strongest cipher suites set as preferred.	✓	✓	✓	326
9.1.3	Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the preferred option.	✓	✓	✓	326

[jmanico]

This looks good on second look, and I see that 9.1.1 talks about dropping down to unencrypted, not dropping down to bad protocols. 9.1.2 focuses on tool use which is rare in ASVS, are we sure about that? But overall this is solid, Josh! - Jim

On 5/18/20 3:52 PM, Josh Grossman wrote: @jmanico <https://github.com/jmanico> did you look at my propsed changes from #771 <#771>? See also below: # Description L1 L2 L3 CWE *9.1.1* Verify that TLS is used for all client connectivity, and does not fall back to insecure or unencrypted communications. (C8 <https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering>) ✓ ✓ ✓ 319 *9.1.2* Verify using online or up to date TLS testing tools that only strong cipher suites are enabled, with the strongest cipher suites set as preferred. ✓ ✓ ✓ 326 *9.1.3* Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the preferred option. ✓ ✓ ✓ 326 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#770 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEBYCIGVDWZL657QGHKKSLRSGGWDANCNFSM4NELYUVQ>.

-- Jim Manico Manicode Security https://www.manicode.com

[jmanico]

Noted. PS You assigned a lot of things to me I have not looked at, this week I'll clean all of those up, so feel free to assign more to me. - Jim

On 5/18/20 3:58 PM, Josh Grossman wrote: Assigned #770 <#770> to @jmanico <https://github.com/jmanico>. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#770 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEBYCPWWC23IMB5IREHJC3RSGHOFANCNFSM4NELYUVQ>.

-- Jim Manico Manicode Security https://www.manicode.com

[jmanico]

Yea your changes are solid, Josh

On 5/18/20 3:46 PM, Josh Grossman wrote: See #770 <#770> where I have made some changes to try and make them clearer. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#770 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEBYCKFWFAKYE7AXVEQIKTRSGGCJANCNFSM4NELYUVQ>.

-- Jim Manico Manicode Security https://www.manicode.com

[tghosth]

@csfreak92 any further comments?

[csfreak92]

@tghosth, @jmanico, I agree. The changes look solid. Although a specific example of an application failing 9.1.1 but not failing 9.1.2 and 9.1.3 or in any combination not failing all these three requirements would help enlighten our team's understanding. Earlier today we were debating about these three specific controls. It seems like if an application being assessed failed 9.1.1, it automatically fails 9.1.2 and 9.1.3. They all look like tied together hence my recommendation to compress them. Thoughts?

[tghosth]

If an application supports well-configured TLS on port 443 but also HTTP on pot 80 then technically it passes 9.1.2 and 9.1.3 but not 9.1.1.