Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
http.sys & ssl on ssllabs get C rating (vulnerable)
#1
After changing one of my applications to use http.sys, the ssllabs rating went from A to C (vulnerable). Any idea why is this and what settings I have to make to get a better rating?

Well, it seems that I always find the answer after I post my question here :-)

This article explains what changes need to be made to get an A rating. You can also run the Powershell script from the article and it does all the changes. Now the mission for A+ rating begins.
Reply
#2
Thanks for the feedback, Ioan. In case of http.sys, all the "security" layer is handled by Windows itself, just like when running as ISAPI. Hopefully, getting an A+ shouldn't be too hard :-)
Reply
#3
(10-17-2018, 08:38 PM)Alexandre Machado Wrote: Thanks for the feedback, Ioan. In case of http.sys, all the  "security" layer is handled by Windows itself, just like when running as ISAPI. Hopefully, getting an A+ shouldn't be too hard :-)

How do you find performance is under http.sys?   I previously deployed as stand alone service and was looking at aspx, but may just go this route.
Reply
#4
http.sys is basically IIS core, so its quite fast.
Reply
#5
(10-16-2018, 07:40 AM)ioan Wrote: After changing one of my applications to use http.sys, the ssllabs rating went from A to C (vulnerable). Any idea why is this and what settings I have to make to get a better rating?

Well, it seems that I always find the answer after I post my question here :-)

This article explains what changes need to be made to get an A rating. You can also run the Powershell script from the article and it does all the changes. Now the mission for A+ rating begins.

I have worked a bit with optimizing SSL security, both with IntraWeb standalone (A+) and with a .NET service using the same built-in SSL security as IIS (A). Windows built-in security level can be crappy by default (especially in older OS versions) and needs to be optimized with regards to ciphers. I used a free tool  called "IIS Crypto" that probably does something similar as the PowerShell script you mention. At least historically, a drawback of using Windows built-in security was that it does not receive security updates when the OS gets older. For example, when we still had some Win2003 servers out there with our software installed (no longer supported, thankfully...), we could maintain A+ rating for our IW web applications simply by updating OpenSSL and adjusting cipher configuration, but could not get higher than C for the .NET service (due to TLS 1.2 not being supported).
Reply
#6
.NET service? Do you mean the SA Service?
Reply
#7
(11-27-2018, 02:12 PM)kudzu Wrote: .NET service? Do you mean the SA Service?

Sorry if I was unclear. I meant a custom Windows service we implemented in .NET which implements a REST web service interface accessed via https. Unlike our IW standalone web applications running on the same machine (which use OpenSSL and *.pem certificate files), it binds to a SSL certificate imported into the Windows certificate store (actually the same certificate in another format). From the SSL security configuration point of view, it is similar to an IW web application running under IIS. I just wanted to share my view that while there can be advantages to using IIS and Windows built-in SSL support, there can also be disadvantages that you might want to consider.
Reply
#8
The latest TLS stuff is fairly complex and the SA servers of IW are built on Indy which does not support it yet. For such needs, this is why we offer IIS, http.sys, etc.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)