Skip to main content

TLS 1.2 and PCI

As you may know, the payment card industry is moving quickly to adopt TLS 1.2 and get rid of less secure protocols.[1] To this end, Authorizet.Net has turned off TLS.1.2 on its sandbox environment as of April 30, 2017. [2]

The curious part about this change is how it impacts the developer world. We have some older projects built using VS2010 (msbuild) and old web deploy projects. Up until April 30, we could build those with .NET 4 and VS2010. So we happily and blindly did that, until May 1.

Starting May 1 we started to see those pesky communication disconnection errors. Darn, what is that? Well, that's the TLS 1.2 requirement in sandbox. So we apply the fix and discover that .NET 4 does not have the TLS 1.2 enum SecurityProtocolType. Well, double bummer.

When we move on to .NET 4.5.1 to get that SecurityProtocolType.Tls12 we discover that we can no longer use VS2010 msbuild. Why? Because that old VisualStudios can't build .NET 4.5.1. [3] How fun is that?

With one change from an unrelated industry our development environment will be forced to phase out anything prior to VS2013, and thus all web deploy projects. Now we have to adopt a different web application build workflow. I am sure we are not alone.

There are alot of developers who resist migrating to newer versions of VS. I remember one guy who was adamant that VS2010 was the best IDE ever built by Microsoft and tried everything to keep it working. We only keep it around for the old web deploy projects for some apps that are huge.

Hasta la vista, baby!


[1] http://help.theatremanager.com/frequently-asked-questions/june-2016-use-tls-11-and-authorizenet
[2] https://github.com/AuthorizeNet/sdk-php/issues/222
[3] http://stackoverflow.com/questions/12390175/targeting-net-framework-4-5-via-visual-studio-2010

Popular posts from this blog

How To Cancel ATT Uverse

I was a subscriber to the AT&T Uverse service for a little over 2 years. In that time, we had experienced good service for the first year, and then it sucked. After 12 months, or there in, the service degraded quickly, and would stop working all together at times. At first it would die for a short period of time, usually when we were not home. Then it would get progressively worst, until there was an entire week of no service. We had technicians at the house trying to fix the service, but it would repeat the behavior quite consistently.

On January 15th we finally gave up and switched to a lesser service, COX TV and Internet. In the past we had cable service and it was always reliable, but not as good as the AT&T digital service. COX doesn't have nearly as many HD channels, but that's not enough. We needed internet to be reliable, and AT&T couldn't deliver that.

Cancelling the AT&T service was a nightmare. Try to find anything about such things on their web si…

Splunk To root or Not To root

Today I added some add-ons to my splunk and did some sysadmin on the server. Restarted and noted the splunkd was not running. Ahh, well, that's typical. Starting the splunk daemon is easy enough:

Start Splunk - from the people who made splunk.

There are two ways to start splunk, as you can read from above. One is to run the "splunk" process from your root shell after logging in. This will run splunk as root. The other is to use the nifty systemctl service script to daemonize the process.

Prior to today, I had the same problem and ran the splunk process as root. This was foolish. If you happen to have once started splunk as root, and then successfully started splunk as the "splunk" user, you will find that your splunk login page is empty. You get the background picture, but no input controls.

Damn. Google that, nada. Damn again.

Today, I learned alot more about selinux and permissions and labels, so I investigated the "web_service" log (/opt/splunk/var/…

Whiskey Tango Foxtrot

Today is one of those Whiskey Tango Foxtrot kind of days. I've been tracking a real November Sierra since December, and even reported it. I figured it was a bug, so I submitted it to the security folks. Their response? "We're not the team for this problem." ok.

Now today I see two data points, one weird-o one-timer kind of probe. Yup, for real, a solo IP in the gigabytes of logs that my splunk eats. Yet this IP correlates with another IP that has been on my radar.

So I get out my splunk and pull a "deny" query on this IP. Not only does it generate IPS hits from my desktop, outbound to destination, but I see inbound activity from this IP (also denied, of course).

(2017-03-29T17:56:44) firewall:msg_id="3000-0150" Deny1-Trusted0-External9840tcp2064 [desktop_ip]184.86.92.711276680offset5A2936268642win