Thanks for the review!

On 08/25/2016 12:50 PM, Eric Covener wrote:
 - If we talk about BREACH we can't just show "SSLCompression off"
because BREACH, IIUC, would affect deflate over TLS not just TLS
compression.

Right, `SSLCompression off` is there to address the general CRIME-type vulnerability. I attempted to address this in the same breath I mentioned BREACH:

Please note that strong encryption does not, by itself, ensure strong security. 
(As an example, HTTP compression oracle attacks such as BREACH may require 
further steps to mitigate.)

It's also the reason I changed the section title from "Enforcing Strong Security" to "Enforcing Strong Encryption". I wanted to focus on attacks against TLS/ciphersuites -- and call out explicitly that that's the only goal of the document -- rather than trying to address all possible attacks against an HTTPS deployment. "Security" is too broad for that IMO.

Maybe that's not the way to go? Should we try to address BREACH explicitly here?

 - The recent stuff about 3DES will probably require a re-sort or
removal (bad timing)

Ah, good point. This only affects the "intermediate" level ciphersuite, unless I'm missing something.

 - IIUC there will be no renegotiation in TLS 1.3, so some of the
ciphers-in-location stuff could maybe use a long-term caveat.

Do we already have a plan for how per-Location SSLCipherSuites will function when 1.3 is deployed? Or were you thinking something more along the lines of "this requires support for TLS renegotiation, which may be removed in a future TLS version; beware"?

--Jacob


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org
For additional commands, e-mail: docs-h...@httpd.apache.org

Reply via email to