Question re TLS versions & compatibility

[proxyheavennhell]

trafficstars

Hey!

Quick question - when using the proxy to access mailboxes with Exchange 365 from Microsoft or Amazon AWS etc - are there any considerations for your proxy regarding TLS versions and connectivity with these?

For example, Both Exchange 365 and Amazon AWS I think only accept TLS 1.2 and lower are deprecated/not supported any more. Obviously your proxy works but just wondering what considerations there may be for this and future restrictions for TLS version? Will your proxy automatically be ok for future proofing here?

Thanks for any advice/clarity

Steve.

[simonrob]

The proxy avoids anything like this as much as possible, and with the exception of setting the minimum TLS version to 1.2, it relies on Python's inbuilt SSL module for its connection configuration. So yes, future-proofing shouldn't be an issue.

[proxyheavennhell]

Thanks v much, that's great.

One more question. I have an install of this and all seems to be fine - all 3 keys from Azure are in config etc, however in the log it shows:

"<-- b'A002 NO AUTHENTICATE failed.\r\n'"

I presume this is still something incorrect either with one or more of the keys? Or other azure setup?

Thanks

[bruor]

I'm attempting to use this proxy on windows 2016 with exchange online, unfortunately it fails to complete the TLS handshake to outlook.office365.com:995 which is requiring TLS 1.2. If I am able to figure out how to get it to work I will post the solution here.

I found a powershell script to test this on windows 11 and it ended up requiring that I set registry keys to enable TLS 1.2 for .net framework. The same registry changes on server 2016 have no effect on the powershell script or this proxy. https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-client#bkmk_net

[simonrob]

One more question. I have an install of this and all seems to be fine - all 3 keys from Azure are in config etc, however in the log it shows:

"<-- b'A002 NO AUTHENTICATE failed.\r\n'"

This could be lots of things, but yes, it's probably on the Azure/Entra side. Very hard to identify without further information however (such as a full debug log and config file).

---

I'm attempting to use this proxy on windows 2016 with exchange online, unfortunately it fails to complete the TLS handshake to outlook.office365.com:995 which is requiring TLS 1.2. If I am able to figure out how to get it to work I will post the solution here.

This is I presume an OS-related issue – there's nothing the proxy can do about O365 requiring a particular version of TLS, so you'll need to find a way to support this. You could of course use the proxy on a separate device and just connect to that from your older OS.

---

I'll close this issue as the two recent comments are unrelated to the original, but feel free to open separate issues about any problems caused by the proxy.