.Net 3.5 and TLS 1.2



  • So this popped up at work today.

    One of our clients is running the version of our software that uses .Net 3.5. They're also using UPS integration. Our site fires a server-side request to UPS's API with shipping address + package info, and we get a shipping rate.

    Except today it stops working. Because UPS decided to require all requests be TLS 1.2 or higher by the end of May but just kidding it's happening now. So API requests are failing, the checkout process can't calculate shipping.

    I'm not sure if this is an IIS change, or a .Net framework change or a code change.

    The call to UPS is happening via a Web Request, but it's inside a compiled dll provided by UPS, so I can't hack it directly.

    So far the only solutions that have been pitched are:

    1. Upgrade the site to .Net 4.0. This may work, or it may have unintended side effects on the rest of the codebase. Quick and easy, but might break.
    2. Create a .Net 4.0 "repeater" API. It will take requests from the site, and bounce them to UPS, then return the results, and nothing else. Billable hours for the client, business days until it's in place, and no guarantee it will work.
    3. Something else?


  • You need .NET 4.5+ to do TLS 1.1 and 1.2. The WebRequest class (used in wrappers for webservice) in older version won't do TLS1.1 and 1.2.

    A quick and temp fix is to install Fiddler to decrypt traffic and reencrpt using TLS 1.2, but it's probably time for you to explore upgrading to .NET 4.5+



  • @Lorne_Kates said:

    One of our clients is running the version of our software that uses .Net 3.5

    This implies that there are versions that do not. Is there an upgrade/migration process in place for older versions to get them to newer versions?

    @Lorne_Kates said:

    Upgrade the site to .Net 4.0. This may work, or it may have unintended side effects on the rest of the codebase. Quick and easy, but might break.

    Ultimately, this is probably the best option. As I see it, if UPS integration is a critical feature, they're already broken, and it's hard to get more broken than broken. Given that the brown guys have made a brown mess over your application, you have a convenient scapegoat and opportunity. Get them running on the latest version, restore the functionality, and deal with any surprises as they emerge. Besides, being stuck on 3.5 in 2016 is... less than ideal.

    @Lorne_Kates said:

    Create a .Net 4.0 "repeater" API. It will take requests from the site, and bounce them to UPS, then return the results, and nothing else. Billable hours for the client, business days until it's in place, and no guarantee it will work.

    This creates another moving part that has to be verified and maintained. How many customers are going to benefit from this API? Doesn't it also provide an incentive not to upgrade?

    @Lorne_Kates said:

    Something else?

    What have you done for other customers? Is everyone else running the latest and greatest?



  • Huh, I didn't believe you, so I checked. You do seem to be correct: https://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.110).aspx



  • Actually, I lose count on how many times such question is asked in MSDN "C# General" and "BCL" forums.



  • You could use stunnel to "upgrade" the connection to TLS 1.2. It's like a transparent SSL proxy, but it's a bit hacky.

    There are probably better solutions, but that's probably the fastest. Also, shame on you for not supporting TLS 1.2. :fishing_pole_and_fish:



  • @Groaner said:

    This implies that there are versions that do not. Is there an upgrade/migration process in place for older versions to get them to newer versions?

    There is, but given how heavily customized the solution is (which itself is an add-on for Navision), it's something that takes an order of magnitude of "months" of planning + labor + testing, and a not-insignificant cost.

    @Groaner said:

    Given that the brown guys have made a brown mess over your application, you have a convenient scapegoat and opportunity.

    This is the brown-tinted silver lining about the whole thing.

    @Groaner said:

    This creates another moving part that has to be verified and maintained. How many customers are going to benefit from this API? Doesn't it also provide an incentive not to upgrade?

    Maybe one other, out of hundreds, specifically for UPS.

    @Groaner said:

    What have you done for other customers? Is everyone else running the latest and greatest?

    I think the only other customer who uses a similar API is already in the process of upgrading to latest & greatest. This is the first customer to come across this issue.

    @rc4 said:

    You could use stunnel to "upgrade" the connection to TLS 1.2. It's like a transparent SSL proxy, but it's a bit hacky.

    Hmm. Will check.



  • I prefer to use Fiddler because it's created by ex-member of IE team and I can trust they know what they're doing.

    Note that you need to download Fiddler4 instead of Fiddler2 to use TLS 1.2.



  • The least dangerous breaking change would be creating a local http listener to act as a proxy. Receive the request on a .net 45 project with http listener and resend request to ups with the right security. Proxy the request back to the main app and do a proper migration of code. When the fire is out.

    You do send requests through a central method, I hope?



  • It doesn't surprise me that .Net 3.5 (2007) doesn't support TLS 1.1 (2006) or 1.2 (2008), but I'm a bit surprised that .Net 4.0 (2009) doesn't support TLS 1.1. I guess at the time that SSL2 wasn't prohibited (that was 2011) and SSL3 wasn't deprecated (2014).



  • That's because the HTTPS implementation for .NET framework is just a wrapper around "schannel". The "flags" it can be passed has to be accepted by all systems it support. Since .NETv4.0 has to support WinXP, it cannot include TLS1.1 and 1.2 which are not supported there.

    Also note that in original plan, since many servers has problem on supporting TLS 1.1 and 1.2, it was not quite expected SSL3 and TLS1.0 will phase out so soon.



  • Fiddler is alright, but it's supposed to be used for analyzing captured traffic, not being an SSL proxy (like stunnel)



  • @cheong said:

    Also note that in original plan, since many servers has problem on supporting TLS 1.1 and 1.2, it was not quite expected SSL3 and TLS1.0 will phase out so soon.

    Oh, yeah, I do remember this. I remember posts from sysadmins asking how to disable TLS 1.1 and 1.2 in Firefox (or was it IE?) enterprise-wide, then people responding, "Why would you do that? TLS is newer than SSL." because so many people make that mistake (seriously, they should've called it TLS 4.0), and then the sysadmins saying, "Yeah, but TLS 1.1 and TLS 1.2 in Firefox won't talk to servers X, Y, and Z."



  • On the other hand, stunnel may be good but needs some configuration and it runs on *nix.

    .NET WebRequest have no problem getting proxy setting of Fidder by simply launching it, and it runs on Windows platform. Therefore it seems better for me for this situation.

    Btw, I keep it open 7x24 for my development Android phone to talk to testing server and outside, so there should be no stability problem for running the RESTful thing over it as short term solution.



  • @cheong said:

    needs some configuration

    Already provided in a link.

    @cheong said:

    and it runs on *nix and windows.

    FTFY



  • It's more about OS support than .Net itself. .net 4.0 ran in WIndows XP; Windows XP's networking layer doesn't support TLS 1.1, 1.2.



  • Yeah, SChannel added support for TLS 1.2 and 1.1 in IE9 (albeit disabled by default), which XP never got.



  • @blakeyrat said:

    It's more about OS support than .Net itself. .net 4.0 ran in WIndows XP; Windows XP's networking layer doesn't support TLS 1.1, 1.2.

    Just like Microsoft to not backport it to XP. They care more about profits than security.



  • XP was out of support.

    That's what "out of support" means.



  • BTW, welcome to the exciting world of UPS integration.



  • @blakeyrat said:

    XP was out of support.

    That's what "out of support" means.

    :whoosh:



  • @Lorne_Kates said:

    There is, but given how heavily customized the solution is (which itself is an add-on for Navision), it's something that takes an order of magnitude of "months" of planning + labor + testing, and a not-insignificant cost.

    Shitsux.

    @Lorne_Kates said:

    Maybe one other, out of hundreds, specifically for UPS.

    I'd think the merits of such ad-hockery would come down to a cost-benefit analysis, depending on how customized these clients' apps are. You'd know better than I in those cases, obviously. If having a compatibility module would help a significant enough number of clients, I'd say go that route. If all the apps are each operating in their own ad-hoc mode, the value of such a customization is diminished.

    Of course, the last two places I've worked at have used the annual support contract model, so billable hours are less of a concern, and at my current place, I've been given free rein to refactor and redesign major parts of our system on several occasions, so maybe I'm biased.



  • Implemented solution:

    STunnel running on localhost, pointing to UPS's endpoint, with TLS 1.2. It works. Client is happy. Minimal billable hours (though it's a pretty chunk).



  • Hello,

    We have recently added a feature for .Net 3.5 allowing applications to optionally use system-default SSL and TLS versions, including TLS 1.2, rather than the versions of TLS now used by default in .Net 3.5.

    To use this feature, you must first install a patch that is specific to each version of Windows, as described in the KB articles below, and then modify the registry as described in each KB article.

    KB3154518 - Reliability Rollup HR-1605 - NDP 2.0 SP2 - Win7 SP1/Win 2008 R2 SP1
    KB3154519 - Reliability Rollup HR-1605 - NDP 2.0 SP2 - Win8 RTM/Win 2012 RTM
    KB3154520 - Reliability Rollup HR-1605 - NDP 2.0 SP2 - Win8.1RTM/Win 2012 R2 RTM
    KB3156421 - 1605 HotFix Rollup through Windows Update for Windows 10.

    Cristian Pop, Microsoft (MSFT)



  • @CIPop said in .Net 3.5 and TLS 1.2:

    including the deprecated TLS 1.2

    Excuse me?



  • @heterodox Thank you for noticing that! TLS1.2 is obviously not deprecated. I've corrected my post above.


  • Winner of the 2016 Presidential Election

    @CIPop said in .Net 3.5 and TLS 1.2:

    MSFT

    Oh wow, we have a MSFT here?

    Welcome to the toxic hellstew!


  • BINNED

    @sloosecannon we're not a toxic hellstew, we're a wretched hive of scum and villainy


  • Impossible Mission - B

    @Jaloopa said in .Net 3.5 and TLS 1.2:

    @sloosecannon we're not a toxic hellstew, we're a wretched hive of scum and villainytrollery

    Come on, get it right!



  • @CIPop said in .Net 3.5 and TLS 1.2:

    KB3154518 - Reliability Rollup HR-1605 - NDP 2.0 SP2 - Win7 SP1/Win 2008 R2 SP1
    KB3154519 - Reliability Rollup HR-1605 - NDP 2.0 SP2 - Win8 RTM/Win 2012 RTM
    KB3154520 - Reliability Rollup HR-1605 - NDP 2.0 SP2 - Win8.1RTM/Win 2012 R2 RTM
    KB3156421 - 1605 HotFix Rollup through Windows Update for Windows 10.

    Wow, was not expecting that. Thank you for the info, I'll pass it to the IT people at work to test and deploy.



  • @sloosecannon said in .Net 3.5 and TLS 1.2:

    Oh wow, we have a MSFT here?

    He must have been searching for .net tls 1.2 on BingGoogle to let people know.



  • @Lorne-Kates

    Hi kate , Does this solution resolve your issue ? if yes, Can you please provide the steps you have followed and issues you have faced?

    KB3154518 - Reliability Rollup HR-1605 - NDP 2.0 SP2 - Win7 SP1/Win 2008 R2 SP1
    KB3154519 - Reliability Rollup HR-1605 - NDP 2.0 SP2 - Win8 RTM/Win 2012 RTM
    KB3154520 - Reliability Rollup HR-1605 - NDP 2.0 SP2 - Win8.1RTM/Win 2012 R2 RTM
    KB3156421 - 1605 HotFix Rollup through Windows Update for Windows 10.



  • @dileep006 said in .Net 3.5 and TLS 1.2:

    Hi kate

    Lorne, are you a trans hooker or what?


    Filed under: we become what we fear, we become what we hate


  • Impossible Mission - B

    @Maciejasjmj said in .Net 3.5 and TLS 1.2:

    we become what we fear, we become what we hate

    ...and Lorne has become a trans hooker named Kate ???





  • @dileep006 said in .Net 3.5 and TLS 1.2:

    Hi kate , Does this solution resolve your issue ? if yes, Can you please provide the steps you have followed and issues you have faced?

    Hi 00,

    I've passed it to the internal dev team. The KB has to go through the usual vetting and testing, which given the time of year, may take a few weeks. I'll let you know if any issues come up.

    Did you want me to reply here, or did you want to PM me some contact info?



  • @Lorne-Kates

    Please share some contact info.



  • @dileep006 said in .Net 3.5 and TLS 1.2:

    @Lorne-Kates

    Please share some contact info.

    That wasn't one of the options Lorne presented there.



  • @heterodox said in .Net 3.5 and TLS 1.2:

    @dileep006 said in .Net 3.5 and TLS 1.2:

    @Lorne-Kates

    Please share some contact info.

    That wasn't one of the options Lorne presented there.

    :pendant:



  • @heterodox said in .Net 3.5 and TLS 1.2:

    @dileep006 said in .Net 3.5 and TLS 1.2:

    @Lorne-Kates

    Please share some contact info.

    That wasn't one of the options Lorne presented there.

    I'm sure Kate is fine with it, though.



  • @Groaner said in .Net 3.5 and TLS 1.2:

    :pendant:

    Well, it wasn't. And it seems presumptive to request something when it wasn't one of the things explicitly offered, but maybe that's just me.



  • @heterodox said in .Net 3.5 and TLS 1.2:

    @Groaner said in .Net 3.5 and TLS 1.2:

    :pendant:

    Well, it wasn't. And it seems presumptive to request something when it wasn't one of the things explicitly offered, but maybe that's just me.

    First, there's a good chance there's a language barrier (and perhaps a culture barrier) here.

    Second, we have people at what one might call the epitome of massive, faceless corporations going around and not only offering helpful support unsolicited, but actually following up on resolution of the issues. I don't know about you, but I think this sort of behavior should be encouraged.



  • @Groaner said in .Net 3.5 and TLS 1.2:

    Second, we have people at what one might call the epitome of massive, faceless corporations going around and not only offering helpful support unsolicited, but actually following up on resolution of the issues. I don't know about you, but I think this sort of behavior should be encouraged.

    I agree with you, if it's done properly. Language and culture barriers can be overcome with training. But if this sort of thing is done without training (I.e., a middle manager deciding, "Hey, browse some social media and tell people we fixed this bug!"), it can make impressions of the company significantly worse. Our second guest looked like he hadn't even read the thread or he would have seen the exact same solution offered. I offer this criticism because I want to see this kind of thing succeed.



  • @Groaner said in .Net 3.5 and TLS 1.2:

    Second, we have people at what one might call the epitome of massive, faceless corporations going around and not only offering helpful support unsolicited, but actually following up on resolution of the issues. I don't know about you, but I think this sort of behavior should be encouraged.

    Assuming that @dileep006 actually belongs to that organization. The other guy identified himself by name and employer. Reading his post, it really looks like he's just asking if the posted solution worked and to send him teh codez:

    @dileep006 said in .Net 3.5 and TLS 1.2:

    @Lorne-Kates

    Hi kate , Does this solution resolve your issue ? if yes, Can you please provide the steps you have followed and issues you have faced?

    KB3154518 - Reliability Rollup HR-1605 - NDP 2.0 SP2 - Win7 SP1/Win 2008 R2 SP1
    KB3154519 - Reliability Rollup HR-1605 - NDP 2.0 SP2 - Win8 RTM/Win 2012 RTM
    KB3154520 - Reliability Rollup HR-1605 - NDP 2.0 SP2 - Win8.1RTM/Win 2012 R2 RTM
    KB3156421 - 1605 HotFix Rollup through Windows Update for Windows 10.

    Also, my super cow powers tell me that the original guy registered with a Microsoft email and the other guy didn't (no, I'm not going to divulge either beyond that). Which could just mean that he used his personal email.



  • @boomzilla said in .Net 3.5 and TLS 1.2:

    @Groaner said in .Net 3.5 and TLS 1.2:

    Second, we have people at what one might call the epitome of massive, faceless corporations going around and not only offering helpful support unsolicited, but actually following up on resolution of the issues. I don't know about you, but I think this sort of behavior should be encouraged.

    Assuming that @dileep006 actually belongs to that organization. The other guy identified himself by name and employer. Reading his post, it really looks like he's just asking if the posted solution worked and to send him teh codez:

    Plausible.

    @dileep006 said in .Net 3.5 and TLS 1.2:

    @Lorne-Kates

    Hi kate , Does this solution resolve your issue ? if yes, Can you please provide the steps you have followed and issues you have faced?

    KB3154518 - Reliability Rollup HR-1605 - NDP 2.0 SP2 - Win7 SP1/Win 2008 R2 SP1
    KB3154519 - Reliability Rollup HR-1605 - NDP 2.0 SP2 - Win8 RTM/Win 2012 RTM
    KB3154520 - Reliability Rollup HR-1605 - NDP 2.0 SP2 - Win8.1RTM/Win 2012 R2 RTM
    KB3156421 - 1605 HotFix Rollup through Windows Update for Windows 10.

    Also, my super cow powers tell me that the original guy registered with a Microsoft email and the other guy didn't (no, I'm not going to divulge either beyond that). Which could just mean that he used his personal email.

    Just as long as he's not one of those Contoso people. I hear they're quite shifty.



  • @Groaner said in .Net 3.5 and TLS 1.2:

    Just as long as he's not one of those Contoso people. I hear they're quite shifty.

    Keep a wary eye open for those Fabrikam types too.


  • Impossible Mission - B

    @No_1 said in .Net 3.5 and TLS 1.2:

    Keep a wary eye open for those Fabrikam types too.

    Yeah, they're even worse than Initrode!





  • @No_1 said in .Net 3.5 and TLS 1.2:

    Fabrikam types

    They aren't half as bad as the guys from Tailspin Toys



  • Third party Implementation here.

    Otherwise welcome to the magic of JustDecompile, reflection and probably PInvoke.

    Also may I mention that .NET 3.5 is now not supported by Microsoft.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.