 Hello. My name is Saravanan. I'm from FI network. So I would like to share with some of the problem that I routinely encounter when working with the customer cases. So I often see a very mysterious TLS handshake failure and the lock from Windows server is not very useful. So after particular investigation I found that when after the client send the client key exchange chainsai prospect and encrypted handshake message it will typically expect a similar chainsai prospect and encrypted from the server. But instead I was directly getting a TCP reset. So upon further investigation I noticed that it always happens only when I use the Diffie helman ephemeral. It doesn't happen if I use ECDHC for example. So as you all know the Diffie helman typically have a common domain parameter then both the parties will exchange their public key and calculate the shared secret and both the parties end up with the same shared secret. So in sometime what can happen is the resulting shared secret may contain a leading 00 byte. So in just cases the TLS 1.2 RFC says you have to remove the leading 00 byte and remaining byte you should use as a pre-master secret. So what I found is Windows external TLS implementation is not RFC compliant. It is not stripping the leading 00 byte and directly taking the resulting thing as a pre-master secret and hence it end up with the wrong master secret and hence is unable to decode the finished message from the other side. So when you will hit the bug is if one of your end point is a non external TLS implementation and the other end point is a Windows external implementation and if you are using DSC and if the shared secret end up with a leading 00 byte then you will hit this particular bug. So when I tested I found it is there in all the 2008, 2012, 2016 all versions contain the same bug. So what I did was since I am not the guy who found this bug it was there for a past couple of years. So I did a quick check on Google. On Google some of the people have already reported this bug but no one there is no public documentation on it. So in order to prove this bug what I did was I realized that on Windows the Diffie-Hellman ephemeral is not 100% ephemeral for up to two hours it used the same parameters again and again. Where do I find this info from one of the old paper called imperfect forward secrecy where it has mentioned Microsoft external catches deep power before two hours. So I used it for my advantage and what I did was I used the call command line and connected to the server once with the DHC with the TLS 1.2 and I noted down the GP and the public key value. Then I wrote a small Python script. I created my own script and I tried what private key if I use I will end up with a shared secret with a leading 00 byte. I noted down that private key and public key and to inject that I used an open source utility called TLS attacker. I used this tool I injected my own custom client key exchange with the calculated value and straight away I can see the bug. So I tested with the to my surprise the bug is also there in some of the old Java version and luckily all these bugs are fixed now in it all are fixed but for the Microsoft site unfortunately one second. From Microsoft site I was checking with our developer whether anybody contacted Microsoft on this. They told yes they filed a bug ID but Microsoft closed the ID telling that Windows 7 is no longer supported and they will consider in future version to fix this bug. But when I tested last year I can still see from this this this but later I contacted a Microsoft developer Andrew Popo he mentioned that he did fix it in the upcoming Windows 2019. So when I tested with 2019 I found that it is indeed fixed but it is not back ported yet. That means you will still encounter this bug. So the reason for getting this bug ID is in TLS 1.0 nothing has been mentioned whether to remove the leading 0.0 or not. Whereas in 1.1 they have clearly mentioned you have to remove the leading 0.0 byte and in 1.2 also they clearly mentioned you have to remove the leading 0.0 byte. So some implementation didn't strip the leading 0.0 and it become a interop issue with the non-compliance. So in summary don't use DHC switch to ECDHC if you have not done it already. I appreciate if Microsoft come up with a public facing documentation explaining this behavior and telling in which version they have fixed it. Otherwise it's creating confusion to the customer. Customers start blabbing the networking vendor third party other vendors. That's all. Thank you.