OWASP Cipher Vulnerabilities

[aligneddev]

I have a non-standard setup (self signed cert, no IIS to avoid that dependency in this small app that will run on a local network, but we want to encrypt the traffic), but according to Rapid 7s Nexpose, I need to disable support for RC4 ciphers, not support Cipher Block Chaining, and "Configure the server to disable support for static key cipher suites." 3.2.3. TLS/SSL Server Supports RC4 Cipher Algorithms (CVE-2013-2566) (rc4-cve-2013-2566) "Configure the server to disable support for RC4 ciphers. For Microsoft IIS web servers, see Microsoft Knowledgebase article 245030 for instructions on disabling rc4 ciphers."

3.3.1. TLS/SSL Server Supports Cipher Block Chaining (CBC) Ciphers (ssl-cbc-ciphers) "Configure the server to favor GCM over CBC regardless of the cipher size. In other words, use Authenticated Encryption with Associated Data (AEAD), e.g. AES-GCM, AES-CCM."

3.3.2. TLS/SSL Server Supports The Use of Static Key Ciphers (ssl-static-key-ciphers) "The server is configured to support ciphers known as static key ciphers. These ciphers don't support "Forward Secrecy". In the new specification for HTTP/2, these ciphers have been blacklisted." "Configure the server to disable support for static key cipher suites."

I also should make sure that TLSv1.2 is being used.

Is there a way in Kestrel or the Asp.Net Core Startup middleware to configure these security settings? this may be what makes me install the full IIS with this app.

var host = new WebHostBuilder()
.UseUrls("http://*:80", "https://*:443")
.UseKestrel(options =>
{
    options.NoDelay = true;
    options.UseHttps(testCertPath, configuration["pfxPassword"]);
    options.UseConnectionLogging();
})
.UseContentRoot(Directory.GetCurrentDirectory())
.UseStartup<Startup>()
.Build();
host.Run();;

[Tratcher]

Kestrel is not currently qualified for edge deployment, you should be using IIS already.

[benaadams]

Says it isn't edge

this small app that will run on a local network, but we want to encrypt the traffic

@logankd its uses to OS algos so is the same disable process e.g. http://www.howtogeek.com/221080/how-to-update-your-windows-server-cipher-suite-for-better-security/

[Tratcher]

It's strange to pay so much attention to TLS security but disregard the HTTP server security.

[benaadams]

A worry of observation vs interference. For example if you were communicating on machine<->machine private network however, you were hosted by a 3rd party you may not be worried about being DoS'd but you may worry about (or have a legal requirement to prevent) a different 3rd party eavesdropping. DoS is more detectable... :wink:

[halter73]

I also should make sure that TLSv1.2 is being used.

Something like the following should work:

.UseKestrel(options =>
{
    options.UseHttps(new HttpsConnectionFilterOptions {
        ServerCertificate = new X509Certificate2(testCertPath, password),
        SslProtocols = SslProtocols.Tls12
    });
})

As far as the cipher options go, Kestrel uses SslStream which uses Schannel on Windows. While I haven't tried this personally, I've read this can be configured globally via some Windows registry keys.

[aligneddev]

Here's some background of how I got here:

• It will be installed a computer in the local network enabling configuration without RDP into that box. This is deployed through an installer file.
• Asp.Net Core was my choice earlier on, thinking that installing full blown IIS could be avoided. I've been learning more that this isn't the best idea. However, I thought that since it was in a local network it would be ok.
• Later in the project a username and password login was added to the requirements. I added it with Asp.Net Identity.
• Then I mentioned that those cred would be passed in the clear from the browser (the user will be on the network, just a different computer) to the computer. "We should encrypt that" came the reply and I agreed :).
  • I created a self-signed cert and added the UseHttps option (article from that learning). We are ok with the scary red warning page in Chrome that says it's invalid (I can't say if this invalidates the full security or not).
• a couple weeks later came the PEN test (which I didn't think about before or know that was a concern). So now I get to handle these, hence the question.

Thank you!

[blowdart]

Cipher suites are selected by the OS, not the web server. So the instructions for IIS would work for Kestrel. There is nothing Kestrel can do to override the cipher suites Windows uses, only the TLS versions it uses,

Having said that we always say that Kestrel is always run behind IIS, or another forwarding proxy, so ...

[guardrex]

Here are some helpful references, too:

https://www.nartac.com/Products/IISCrypto https://wiki.mozilla.org/Security/Server_Side_TLS https://technet.microsoft.com/en-us/library/dn786419(v=ws.11).aspx

[aligneddev]

@halter73 Thank you for the code. I'm looking into the other links given above. @GuardRex I'll suggest the IISCrypto tool to the Ops guys setting up the computer image.

[blowdart]

@benaadams local networks still aren't generally trustworthy GRIN

[benaadams]

@blowdart not recommending it :smile:

[aligneddev]

@halter73 What is the default value for SslProtocols? I would think that it should be Tls1.2 (+ in the future) so that things are more secure by default. The older options wouldn't be needed (there is probably some use case, but why would someone chose to use the lower?).

I wasn't able to figure out the default from, but I haven't pulled down the full code base yet. https://github.com/aspnet/KestrelHttpServer/blob/dev/test/Microsoft.AspNetCore.Server.KestrelTests/HttpsConnectionFilterTests.cs

[halter73]

TLS 1.1 + TLS 1.2 is the current default.

[muratg]

We are closing this issue because no further action is planned for this issue. If you still have any issues or questions, please log a new issue with any additional details that you have.

[kdaveid]

Since kestrel is edge-ready, this is related to #1865