This one came in via email from Philippe:
You’d think that a company with the page title “SSL Certificates from a Leading SSL Certificate Authority” could do a little better.
Michael submitted this SSL fail to us from the ICICI Bank Canada website. Another interesting thing about this website is that with javascript blocked, the default page won’t even load because they use a javascript redirect to send you to the main page (I suppose setting the DefaultDocuments directive (or rather the IIS equivalent) is too difficult).
Here’s the image:
SANS ISC is reporting that people are receiving spam indicating that a server upgrade is occurring and people will need to manually update their SSL certificates. As if there weren’t already enough problems with SSL.
I have to say, this is interesting and if anyone has any examples of the message (with mail headers) or a valid email link, please share it with me (treguly@thisdomain).
Anyone who tried to access SSLFail.com late last night or this morning would have noticed that it was down. I apparently caused my own server outage with python. Here’s how it happened.
When sockstress was first discussed I was rather intrigued and thought about it for a bit, but then I quickly abandoned it… I just had too many other things on my plate. However discussions at SecTOR renewed my interest in exploring how this tool worked. After a bit of googling, I found this page which gives an explanation of what is occurring, although I wasn’t sure if it was correct. It did, however, fit with the ‘TCP/IP Zero Window Size Vulnerability’ in MS09-048.
I decided I would code up the diagram on the Check Point page and see what happened when I tested it. I started writing in python using SOCK_RAW and was ready to send my first packet… or so I’d thought. I forgot to send an appropriate Ethernet header, which meant parsing the packet found garbage instead of a valid packet… and port security on on the switch found an invalid MAC address and quickly disabled the port. Which means no more using the SSLFail.com server for playing with raw sockets.
Anyways, everything is back up and running now.
I just wanted to point to an awesome article from Kelly Jackson Higgins on DarkReading. I can call it awesome because it’s about the SSLFail panel at SecTOR and includes quite a bit of the information we shared with attendees, so for anyone not at SecTOR and not wanting to look at the raw data (which is coming soon)… it provides an awesome overview. Mike and I really enjoyed the opportunity to sit down and talk with Kelly and had realized at the end of the call that we had a much better idea of what we were going to discuss on the panel than we did before the interview. So everyone who enjoyed the discussion points on the panel has Kelly to thank for that.
I want to call the SSLFail.com panel at SecTOR a great success. We had a great time up there and if the audience participating was any indication (and it seems to be) then then it was a good time for everyone. We ended up talking so long that we were kicked out of the room because the next speaker needed to get on the stage to prepare for his presentation. So we migrated to the hallways and answered a few more questions. We also managed to have things to throw at the audience (vendor swag from nCircle (t-shirts) and ForeScout (stress blocks)), so thank you to both vendors. I’m hoping that people took something way from the talk but if there are questions and follow-ups please feel free to contact us, email can be sent to treguly [at] sslfail [dot] com, and I’ll be more than happy to pass it along to the other panelists. I really think we gained as much, if not more, than the attendees and I expect there will be some blog posts posted here over the next few weeks to discuss various things.
For now, I just wanted to say thank you to everyone that skipped two amazing talks to sit through ours, it was definitely appreciated.
I’ve been a huge fan of SecTor since the first year it ran and have been fairly vocal about people attending. This year there’s an extra special reason to attend though, a couple of SSLFail.com bloggers will be doing a panel, we may even have a special guest join us. You’ll have to attend the talk to find out.
As for the subject… we don’t really know. In fact we’re a week away from presenting and it’s still up in the air to some extent. From what I’ve heard you can expect Lolcats, interesting information and some survey results. Anyways, if you’re at SecTor and the Nsploit and Ghostnet talks are full (and I suspect they will be, I wanted to see both of them)… we’re the only option you have left — so come and join us!
A while back we posted a screenshot of the Rogers Webmail SSLFail. I decided to follow-up with Rogers to see if they were going to resolve the issue anytime soon. I contacted Rogers and asked if they were going to fix the issue, a couple of days later (July 11th) I received a canned response with no real information:
Dear Tyler,
Thank you for taking the time to write to us, we appreciate your use of
online customer service.In your recent email, you have informed us that you would like to know
when we will fix an issue with SSL warnings.Please accept our apologies for any difficulties that you may have
experienced while using Rogers services. Rogers strives for excellence
in customer service and we’re sorry that we did not meet your
expectations. Be assured that we take your concerns very seriously, and
appreciate the feedback that you have provided and this has been sent to
the appropriate group for their review. If you have any further
questions or requests please let us know.Thank you for contacting Rogers. For additional information please visit
our website at www.rogers.com. You are a valued customer and we thank
you for your business.For future email correspondence with respect to this e-mail, please
quote reference number XXXXXXXX
I have recieved no additional communication to let me know if they would be fixing this issue or not. I’m guessing they don’t take their SSL issues to be very serious as the issue still exists.
As a side note, in order to contact Rogers about a “website issue”, I had to provide an account number. The account 12345679 was accepted, but I couldn’t believe I needed an account number in order to contact them about there website. That’s ridiculous.
I have to say that when I came across this blog post, I just sat there laughing. Then I stopped laughing when I realized what an issue this is, could you imagine if many sites started doing this and people believed that their transactions were “secured” by SSL. Everyone talks about compliance standards but maybe we need something a little more serious. A way of shutting down sites that do something like this, or at the very least, a fine that causes severe monetary impact to their business.
I realize that you can’t police the internet, but individual countries can police companies that operate within their borders, so let’s start there. We simply need someone to bring it up at the G8 meeting, after all this is much more important than all the discussions on the fictitious issue of global warming. If you require a business permit to operate in a business legally and have to pay taxes and abide by laws, subject the companies to additional regulations related to tricking the customer on the web, or not following best practices. It’s that simple.
I’m sure people will argue that it’s impossible to police the internet, which is why you stick to this per country basis. There will always be malicious sites that dupe the user… that’s unavoidable but in the countries that can do something… do it. Punish these businesses for malicious actions. Take the example that started this post, slap aferry.co.uk with a $10,000 fine. See if they bypass buying that $10 SSL cert again.
We had an interesting screen shot sent in today from Sheldon (his post on the subject). It appears as though the SSL certificate on LinkedIn expired today and they waited until after the expiration to update their cert, leaving people with SSL errors temporarily. This doesn’t seem like a great way to foster user trust, I’d prefer my sites update their certificates early, rather than wait for them to expire. If this was a matter of they forgot the date and weren’t ready for the expiration, then I’m really concerned, that mistake should not happen… especially with a site I trust with so much of my personal information.
