0

I'm investigating significant performance problems with MSIE using TLS connections. I am trying to restrict the available algorithms to isolate the problem / see if there is valid workaround. To do this, I set the SSL cipher suite preference in the Group Policy Editor on the local machine to include only 2 AES128 based algorithms (I suspect the issue is in the asymmetric encryption, this was just to test if the method was valid). However when I apply the policy and start a new MIE instance, it still uses an AES256 suite - i.e. not on on the list I specified.

Its MSIE 11 on MS Server 2012R2.

Am I missing something?

symcbean
  • 18,278
  • 39
  • 73
  • How to configure Windows or IE (even for TLS settings) seems off-topic here? – schroeder Nov 15 '18 at 10:48
  • Maybe - but I was expecting a more capable audience here than on superuser or serverfault (where I've seen similar questions and the quality of the answers) – symcbean Nov 15 '18 at 11:29
  • While I appreciate that you think that the more capable people are here, we do have to keep the subject areas in the correct areas. – schroeder Nov 15 '18 at 11:36
  • Also note that you're probably not far off in your assessment on the asymmetric crypto. MS has had significant problems with single-threading high volumes of asymmetric operations. As an example, if you require signing of network communications (e.g. file server and workstation), and you push a large file, you'll notice horrendous transfer speeds. And this is because SMB is digitially signing each packet with a single thread. Turn it off and you'll see your speeds increase by at least an order of magnitude. 2008 has a patch nothing after does -- thanks MS. – thepip3r Nov 15 '18 at 14:48

1 Answers1

1

Did you notice this little message on the microsoft article you posted??:

It is necessary to restart the computer after modifying this setting for the changes to take effect.

You also didn't mention it but have you checked to ensure the setting is actually applying? 

gpresult /h policy.html
thepip3r
  • 633
  • 3
  • 8
  • Doh! Sometimes its the simple things. Interestingly it turns out the problem is not the SSL, but rather that Microsoft's DNS client applies non-standard processing to the resolution of of CRL server hostname. – symcbean Nov 23 '18 at 22:55