04-08-2019 11:45 AM
04-09-2019 02:42 PM
04-09-2019 02:55 PM
Thanks for your replies. I checked some sites last night which didn't work. Reinstalled tonight and it is now working the same as my Chrome. SSL Labs site reports TLS 1.2 in use with experimental 1.3 as expected
Not entirely sure why it didnt work yesterday, though maybe because I also have Windows insider too perhaps?
04-09-2019 03:01 PM
05-10-2019 07:54 AM
@Avaza It's unlikely that the original poster's issue was with IIS (as Chrome would exhibit matching behavior and apparently it started working as expected later).
In terms of Windows Server's roadmap for TLS/1.3 support in IIS, you'll probably get a better informed answer over in https://techcommunity.microsoft.com/t5/Microsoft-IIS/ct-p/Microsoft-IIS
06-16-2019 11:01 AM
@danmurphy No, TLS 1.3 is not a 'badly needed feature' and the speed benefits are not 'immense,' unless you are TLS servers on old consumer level hardware that lack AES accelerators.
Microsoft is not like garbage developers - I mean open source developers that race to implement something for the personal gratification rather than for the quality of the product. MS, RSA and Cisco have the only TLS 1.0 implementations without active exploits because of it where nearly all other implementations do.
In addition, TLS 1.3 was only ratified a few months ago. All efforts so far are based on code written before the standard was ratified and have extreme likelihood of containing legacy code that will provide a vector for exploit. In addition, these open source projects have also carelessly introduced exploits into TLS 1.3 that do not exist in 1.2, and simply having 1.3 enabled enables downgrade attacks against weaker protocols that can be completely broken.
Wait for a correct implementation. Most (other than the ones where the protocol was fundamentally broken) of the famous SSL and TLS exploits have been created by bad open source solutions that incorrectly implemented SSL/TLS. You will see no difference in performance, other than perhaps at low power client devices.
06-16-2019 11:07 AM
06-16-2019 11:24 AM
1. No MS did not release support for TLS 1.2 within 6 months. TLS 1.2 was ratified in August of 2008. NT 6.1 RTMed at the end of July 2009. That is nearly a year.
2. It doesn't matter. TLS 1.3 is not the same thing as TLS 1.2. TLS 1.3 is a radical update to the protocol, so much so that it was nearly named TLS 2.0. Correctly implementing it will take time. If you are fine with settling for exploit-ridden, incorrect implementations of 1.3 currently available, then you cannot claim to care about anything you claim to care about in the implementation. TLS 1.2 is also not yet exploitable and is better than every incorrect implementation of 1.3 out there.
3. Mathematical differences in speed are not measurable differences in speed. It doesn't matter how much you insist there will be a measurable difference between 1.3 and 1.2, it wont be there. Your part about latency is correct, but in order for latency to come into play in speed - which would manifest only through avoiding some packet loss - you will have to be into latencies of 600-700 milliseconds with high jitter, or 800-900 milliseconds or higher with consistent latency. In other words, EXTREME low end satellite service or extraordinarily busy site to site microwave links.
4. IIS is an HTTP server, not a TLS server. The two have absolutely NOTHING to do with each other. Windows keeping an incorrect implementation of TLS out of the operating system which opens up exploits that never existed before, in place of a TLS 1.2 that currently cannot be exploited is foolhardy at best.
06-16-2019 11:51 AM
06-16-2019 11:52 AM
06-16-2019 12:34 PM
1. The windows insider program didn't exist until Windows 10. If you meant the beta program, well that is completely irrelevant. Until Windows 10, Betas were exclusively used for pre-validation of applications, drivers, etc, and all were pretty much universally extremely unstable and unusable.
2. No, it doesn't.
3. No it isn't. Mathematically faster and something that is perceivably faster aren't the same thing. You seem to be exclusively focusing on web pages and other client apps, but no person is ever going to notice a difference of 200 milliseconds when the client applications takes thousands of milliseconds to render a page, or establish a SIP connection to the server. You aren't saving 200 milliseconds between australia and the united states either. I have a training web application that is hosted in Australia behind a cloud load balancer and typically only see latency of about 5-600 milliseconds in the health check which includes the ~300 or so milliseconds of establishing each session, which would only be incurred once in real use.
In ecommerce sites and content delivery networks these small gains could definitely measurably impact their business, but both of these segments are usually slow to implement new technology, because 1, both of them have to work all the time without exception, and 2, ecommerce has to be secure without exception and content delivery networks may have to be very strictly secure as well.
4. Implementing TLS is not even close to being the same thing as writing a patch for an application, and no exploit discovered within less than a year of the protocol's ratification due to incorrect implementation is even nominally acceptable. Virtually every TLS 1.3 client and server introduced multiple exploits enabling attack vectors at both ends, that allowed easy and difficult to detect downgrade attacks, abd if enabled allowed for easy downgrade to SSL 3.0 or TLS 1.0 - which more than likely was another incorrect TLS implementation containing exploits. Cutting corners is exactly what you are suggesting. Every single current implementation of TLS 1.3 cut corners and exposed every single one of it's users. In less than a year.
07-11-2019 06:44 AM
07-11-2019 07:55 AM
07-11-2019 09:28 AM - edited 07-11-2019 09:38 AM
Hmm, I added the policy key and restarted all browser session SSL test = no change, TLS 1 to 1.3 as yes.
I used command line msedge.exe --ssl-version-min=tls1.2 and it
still tests with 1.0 as yes
EDITED It took a full computer restart and then this worked.
Opened InPrivate tab still tests as yes for 1.0.
I have successfully set policy key for regular Chrome (\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\SSLVersionMin) and it was detected and works as expected.
I'll just have to create a shortcut using "msedge.exe --ssl-version-min=tls1.2"
Any other suggestions?
07-12-2019 08:59 AM
07-12-2019 10:09 AM
07-12-2019 10:09 AM
07-12-2019 10:12 AM - edited 07-12-2019 10:13 AM
07-12-2019 10:12 AM - edited 07-12-2019 10:13 AM
i was trying --cipher-suite-blacklist i doesn't know it was denylist now
07-12-2019 12:40 PM
Opened the URL you gave and read that.
Win key + R key, Entered regedit clicked OK.
Add New Key Chromium
Then in that key add a String value named SSLVersionMin
set the value of that to tls1.2
This is the same process I followed to get the Chrome browser shown below to work. Except it is in the Chrome Key under Google.
Is there supposed to be a another Parent key in between named something like MSEdge ? ie. Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\MSEdge\Chromium ?
07-12-2019 12:48 PM
07-12-2019 01:03 PM
01-04-2020 11:46 AM
It is nice that Edge and Windows 10 and 2019 support TLS 1.3.
However some Windows Update Servers (like fe2.update.microsoft.com on their IPv6 addresses) only support those Ciphers that are known to be weak. Disabling those ciphers in Windows 10 or 2016/2019 breaks Windows Update functionality. So more security actually turns into less security.