Learn something new every day - Clear SSL state

I have known for years, as have most Windows OS users, that sometimes Internet Explorer caches data and refuses to let it go. This is especially frustrating when you're trying to test changes to a web site, and you keep getting the old version. Sometimes CTRL-F5 will force a reload, but sometimes you have to go into settings and manually clear your cache and cookies.

Well, I ran across something new this morning. We have an application that makes an SSL connection to a server. That connection was failing. We could ping the target server, run a trace route to it, all of that, so it wasn't a general network failure. However, whenever the application tried to connect, we were getting an error that said "SendSSLMessageBlocking error 12057".

A quick call to the vendor indicated that it was an SSL certificate issue of some sort. They had us uncheck “Check for server certificate revocation*” in the Advanced settings, yet that didn't fix the problem.

Well, Google to the rescue, as usual!!

I ran across this post on Google Groups about an issue with GMail Notifier throwing the same error.

Did you know that Internet Explorer/Windows also has an SSL certificate cache? And that it can get corrupted?

After a quick click of the "Clear SSL state" button on the Content tab and a restart of the service that was failing, everything is back up and running now.

It's a good day if you learn something new.

Siri-ously broken

Thanks to Tim O'Reilly's twitter feed, I found out about this article explaining how the protocol used by Siri has been cracked.

First, the only surprise is that cracking Siri took as long as it did. Second, it does seem that while Apple tried to implement some security in the protocol, their implementation was still susceptible to a "man in the middle" style attack. Third, it's quite the interesting read in how developers/hackers/crackers go about the process of reverse-engineering a protocol in order to bust it wide open.

So, if you're technically inclined, there's enough information there to write your own app to utilize the Siri protocol.

The next interesting item will be seeing how Apple responds to this in order to lock it all back down again.

Comprehension is apparently a lost art

The following conversation occurred in an email thread:

Me: I cannot ping or browse to the server name you gave me.  Also, I need to know the UNC path to the directory where I'm supposed to drop the files.
Him: (forwarding an old email) You mean this server?
Me: Yes, that one (copies and pastes in the ping results)
Him: Oh, I had a typo in the server name.  Oh, and here's the FTP account information you need.
Me: Um, my process doesn't use FTP.  It uses UNC paths to a file share.  I need either the UNC path or if this process is going to run local on that server, the actual physical path.
Him: FTP is not configured on that server yet, but it's getting set up today.
Me: o.O

Seriously, people.  I've been in 3 meetings for this project, and in each one I specified that the process we're migrating uses UNC, not FTP.  It would require a significant rewrite to get it to use FTP.  I even sent out email messages documenting that requirement.

Reading comprehension is not that difficult.  Oh, and when you are a Business Analyst and part of your job function is gathering and documenting requirements, don't you think it would be a good idea to actually make note of an iron-clad requirement that is called out?

Color me unimpressed with this particular BA.

Riddle me this, Batman.

So, what's the difference between these two things?

1. FILENAME.TXT
2. FILENAME.txt

Nothing, right, especially if you're on a Windows system?¹

Well, according to one of our ASP vendors they are completely different.  We are setting up a new interface with them, and have been testing the process through their automated web-portal upload tool.  Item #2 works just perfectly fine.  However, if we try to upload a file named like Item #1, their portal tells us that it's not a valid text file.

As a developer, this makes absolutely no sense to me.  If you are determining file type based on the extension, instead of inspecting the file itself or letting the user specify the file type, then obviously you're approaching this with a Windows-centric mindset.  After all, file extensions don't have any inherent meaning on UNIX/Linux systems, at least not like on a Windows box.  So, that being the case, how difficult is to either either use a ToUpper() or ToLower() type function on the filename, and then inspect the extension?  To require your clients to meet an arbitrary filename case rule is just asinine.

What makes it even more frustrating is that the application that generates the file is a DOS-based app, so it is going through the DOS command interpreter.  Since the DOS command interpreter does not register an entry for long file name, the file name is automatically converted to all upper-case by the system.  The only way to get the file to load is for the user to manually rename the file, changing the case of the extension.

*mumble* *mutter* GRAH!!!!!!

That is just stupid, horrible, disgusting, nasty code, and this is a major national ASP in this particular product space.  (No, it's not Microsoft).

¹For the purposes of this argument I will ignore Posix-compliant filing systems that treat all file names as case-sensitive.  I develop software that runs on Windows systems.