TLS 1.0

Similar to my question about RC4, are there any issues with version of the eSELECTplus_dotNet_API.dll in regards to the removal of support of TLS 1.0 from the Moneris portals?


I see that a version 4.4 of the Dll is newly available from a GitHub repository.  I haven't had the chance to play with it, but the "4" in the version number makes me nervous.

I have a dependency on .Net Framework 2.0, so I am hoping that if version (of the .Net Framework 1.1 days) has a TLS 1.0 problem, that the version 4.4 Dll is at least still compatible with .Net Framework 2.0.

I would appreciate if someone could address these concerns, as I won't be able to determine whether I have a TLS 1.0 problem (by trial and error that is) myself until Feb 1, 2017.

  • The DLL itself should work on TLS 1.1 & 1.2 but we do encourage that you test your environment in our QA environment once we update in January.
  • In reply to ME_Moneris:

    Do we have to update the DDL itself or will the old one still work?

    We never received any confirmation yet as to whether the test environments have been updated. Can you please confirm?

    Thank you.
  • In reply to jonny:

    TLS 1.0 was disabled in the QA environments today.
  • In reply to ME_Moneris:

    A blog post about that would be really useful. My transaction verifications have just stopped working, and I didn't have much to go on about what the problem was, other than it was TLS related.

    It seems C# defaults to TLS 1.0, so I had to force it to use TLS 1.2 by adding the following line before my call:
    System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
  • In reply to IanThomas:

    I was pleasantly surprise to find out that even though the new Dll is at version 4.4, it is compiled for .Net Framework 2.0,

    Then I was disappointed to discover that it appears Ian's fix only works for .Net Framework 4.5 and above. This is because the constants required to change the version of TLS being used were first defined in .Net Framework 4.5.

    For me this is a forced upgrade to .Net Framework 4.5 as a result.
  • In reply to WaiverWireAddict:

    Did you try manually setting the security protocols instead of using the constants, as such:

    ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

    This is the definition of the Securityprotocoltype enum:

    public enum SecurityProtocolType
    Ssl3 = 48,
    Tls = 192,
    Tls11 = 768,
    Tls12 = 3072,

  • Could anyone point me to where I can find version 4.4 you mentioned? I see only version 2.5.6 on GitHub, which is the one I am currently using in production. Does it solve the issue with TLS 1.2, or is that forced default still required?

  • In reply to Herman:

    4.4 is the File version. I believe 4.4 was version 2.5.5 from GitHub. I got it from gitHub.
  • In reply to ME_Moneris:

    Haven't tried that but I'm not sure I would trust that. I don't know much about the difference between TLS 1.0 and later versions, but if 1.0 is being retired for security concerns, then I assume there is a meaningful difference in the protocol that must be reflected in the code used to implement it, that is a difference beyond the value of a constant. If the constant value is not defined in the 2.0 framework, I am not expecting the 2.0 framework to have a "hidden" implementation of TLS 1.2. I can be wrong of course, I haven't decompiled the 2.0 framework assemblies, but I think my time is better spent working on upgrading all my 2.0 code to 4.5.