#StackBounty: #ssl #windows-server-2012-r2 #iis-8 #google-chrome #microsoft-edge Chromium Browsers TLS1.2 Fails with ADCS issued certif…

Bounty: 50

tl;dr: TLS 1.2 between Server 2012 R2 and Chromium based browsers fails when using AD CS issued certs. Works fine on Server 2016+, and on 2012 R2 with Firefox/IE/Cygwin-curl.

We have several internal Server 2012 R2 web servers which we are trying to move off of publicly issued certificates, onto ones issued by our AD integrated CA, and eliminate less secure crypto settings, including CBC MAC. Server 2012 R2 does not support ECDHE_RSA with GCM, which means that we’re trying to use an ECDH based certs. We have experienced a similar issue, however, when we allow cipher suites with CBC-MAC, such as TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 with an RSA cert issued from the same CA. Using our public wildcard cert issued by GlobalSign, we’re able to connect with all browsers.

The enterprise CA, and the offline root CA are both trusted, and we’ve verified that this is working properly. Certificates using multiple different templates issued to 2016 and 2019 servers work without issue across all browsers. The ECDH and RSA based templateswork equally well on 2016+.

ECDH certificate template crypto:
ECDH cert template crypto settings.

RSA certificate template crypto:
RSA cert template crypto settings.

Both RSA and ECDH certificates on the 2012 R2 servers are accepted by Firefox (once it’s been told to trust them both via policy, and manually setting security.enterprise_roots.enabled), pre-Chromium Edge, IE, and Cygwin’s curl and wget. I’ve confirmed we’re using modern ciphers in the registry, re-setting them with IISCrypto, and verified there are compatible available ciphers being offered by the server with OpenSSL, and nmap. Likewise, I’ve confirmed that clients are actually able to connect using those ciphers.

Firefox shows it’s connecting with TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, which according to Qualys is supported in the version of Chrome which we’re using.

With the ECDH

PORT    STATE SERVICE
443/tcp open  https
| ciphers:
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: A

Each time we try to connect with Chrome a pair of event 36874/36888 are logged stating there were no supported cipher suites on the client.

A list of the cipher suites we experience the issue with when using an Enterprise CA issued cert, most of which were enabled just for testing (warnings snipped):

PORT    STATE SERVICE
443/tcp open  https
| ciphers:
|   SSLv3:
|     ciphers:
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: C

My questions are:

  1. Why do Chromium based browsers fail to negotiate a cipher suite when there are compatible cipher suites offered by the server?
  2. What do I need to set in order to allow Server 2012 R2 to use internally issued certs?
  3. Is there a better way to handle what I’m trying to do, aside from upgrading the application servers to 2016/2019? At this point, it seems like disabling TLS completely and putting everything behind a LB/reverse proxy, even if these are single-server solutions.


Get this bounty!!!

#StackBounty: #windows #windows-10 #google-chrome #microsoft-edge #hdr What do different HDR monitor support capabilities mean in Windo…

Bounty: 100

In Windows HD Color Settings I can see three types of HDR support:

From hardware point of view, such distinction is quite strange, because it doesn’t matter for monitor what type of content to display.

Moreover, YouTube streams in HDR in Edge unlike Chrome (and the difference is noticeable), so the display definitely supports at least some kind of HDR.

So, is there some kind of hardware distinction, or is it just matter of drivers/settings/etc.? If the second is the case, are there any hacks to turn Stream HDR video capability into the other two?

P.S. My device is Lenovo Yoga 720 15 4k version


Get this bounty!!!

#StackBounty: #vue.js #babeljs #microsoft-edge #vue-cli-3 #browser-support Vue Babel outputting incompatible code disregarding browsers…

Bounty: 50

I have a Vue CLI 3 project that I am building. The built code seems to disregard broswerslist. It outputs code that breaks Microsoft Edge regardless if I add Edge to browserslist or not.

The syntax that is being output is the parameter spread operator in a lambda like

(...x) => {}

This is unsupported by a certain version of Edge, and my project keeps outputting it !

These are some of my files:

package.json

{
  "name": "my-app",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "serve": "vue-cli-service serve",
    "build": "vue-cli-service build",
    "lint": "vue-cli-service lint"
  },
  "dependencies": {
    "await-mutex": "^1.0.2",
    "axios": "^0.18.0",
    "bootstrap": "^4.3.1",
    "bootstrap-vue": "^2.0.0-rc.15",
    "json5-loader": "^1.0.1",
    "jwt-decode": "^2.2.0",
    "lodash": "^4.17.11",
    "popper.js": "^1.14.7",
    "pretty-checkbox-vue": "^1.1.9",
    "vee-validate": "^2.2.0",
    "vue": "^2.6.9",
    "vue-router": "^3.0.2",
    "vuex": "^3.1.0",
    "tiptap": "^1.14.0"
  },
  "devDependencies": {
    "@types/lodash": "^4.14.123",
    "@vue/cli-plugin-babel": "^3.5.1",
    "@vue/cli-plugin-eslint": "^3.5.1",
    "@vue/cli-plugin-typescript": "^3.5.1",
    "@vue/cli-service": "^3.5.1",
    "@vue/eslint-config-typescript": "^3.0.5",
    "@types/jwt-decode": "^2.2.1",
    "node-sass": "^4.9.0",
    "sass-loader": "^7.0.1",
    "typescript": "^3.0.0",
    "vue-template-compiler": "^2.6.9"
  }
}

.browserslistrc

> 1%
last 2 versions
edge 15
not ie <= 8

babel.config.js

module.exports = {
  presets: [
    '@vue/app',
  ],
}

What I have tried:

  1. Removing Typescript from project
  2. Changing .browserslistrc with invalid browser to check if it’s reading the file or not, and the build crashed because of browser not found (means it’s reading the file).
  3. Settings .browserslistrc to “ie 11”, and it still outputs lambdas and spread operators.


Get this bounty!!!