If you’re working with SSL (whether websites or otherwise), it sometimes helps to be able to send text and commands directly to the server, but it’s not as easy as just telnetting to the server like with non-SSL servers. That’s where s_client comes in. It’s part of the openSSL suite, so you’ll find it on all unix based systems, and can compile it on Windows based systems.

s_client handles all of the SSL negotiation, with you controlling as much of the negotiation as you want. You can tell s_client what algorithms to “support”, and if the server will complete the negotiation, you know that the server supports that algorithm as well. This is useful to determine if a server supports weak algorithms.

s_client also acts like telnet. So if all you need to do is negotiate the SSL, s_client will handle all of that. If you’re trying to debug SSL, s_client lets you do that as well.

All of the options are listed at the OpenSSL documentation page, but I’ll cover some of the most common ones here.

To just create an SSL connection, use
openssl s_client -connect host:port

The certificates that belong to the server will be displayed, along with the algorithm that was negotiated.

To see if the server supports weak algorithms, you can use
openssl s_client -connect host:port -ssl2 -cipher cipherlist
Where cipherlist looks like CIPHER1:CIPHER2:CIPHER3 The server will select the first cipher in the list it will accept. You can use the openssl ciphers command to see the specific list of ciphers that your copy of OpenSSL supports, or you can refer to the documentation, which also includes “ciphers” such as EXPORT and eNULL – which means export level or no encryption.
Generally, I use
openssl s_client -connect host:port -ssl2 -ciphers eNULL:EXPORT

s_client is a useful tool both for diagnosing SSL/TLS problems, and for checking on the cipher strengths a server supports.

The internet is full of unsavory characters who want to steal your personal information and/or money. This has been widely accepted for quite some time. Recently, some good articles have appeared online regarding what to do if you think you’re being scammed, especially by pop-up ads that look like anti-virus software (http://www.fbi.gov/pressrel/pressrel09/popup121109.htm, http://voices.washingtonpost.com/securityfix/2009/09/what_to_do_when_rogue_anti-vir.html).

While these articles focus on what to do if you’re hit with such an attack, I’d like to present a few rules of thumb that I use whenever I see any type of message that looks suspicious, whether it is from a pop-up ad, e-mail or letter that purports to be from my bank, or even an unexpected phone call from someone claiming to be from a company where I hold an account.

1. Am I being asked for personal details?
   If an incoming message of any type, be it e-mail, pop-up, or phone call, is asking you for personal information or, especially, passwords, then there is a near 0 chance that it is legitimate. Disregard the message immediately.
2. Does the message sender look familiar?
   If you receive a virus notification pop-up that looks like it came from Norton Anti-Virus, and you do not have that product installed on your computer, it’s probably not legitimate. Similarly, if you receive an e-mail from PNC bank and do not have an account there, you can assume the same thing.
3. Is the message informing you of an unexpected change?
   For example, if you receive an e-mail from a financial institution that their web site URL has changed, this is immediately suspect. This is a very rare occurrence, and when it does occur, you will usually be informed by postal mail in a message that conveys the sender’s authenticity. For example, a bank may send you a notice of change that requires no action on your part, and lists your name, address and account number on the letter. If the sender already has information like this, then there would be no need to scam you in the first place.
4. Was I expecting this message, or is the message benign?
   If you receive a message containing expected or benign information, such as a notification that your statement is available, there’s likely no reason to worry. Generally this sort of notification doesn’t even ask for any action on your part.
5. Does the message make you afraid?
   Generally, any unsolicited message that tries to scare you into performing an action you otherwise wouldn’t, such as entering credit card information or revealing a password, by threatening financial loss (in case of phishing) or data loss (in the case of false virus pop-ups), should not be trusted.

   For virus pop-ups, if you are afraid that you have malware installed, disconnect from the internet, shut down and restart your computer, and run a virus scan using anti-virus software that you installed. If you do not have anti-virus software there are plenty of available free options, such as Microsoft Security Essentials. The information in the links above is also quite helpful for this situation.

   For phishing e-mails, do not click on any links in the message. Instead, manually open a browser and navigate to your bank’s web site manually to log in. Alternatively, look up your local branch’s phone number in a phone book and call them during business hours. (Don’t trust any phone numbers listed in the e-mail, either!)

   For suspicious phone calls, do not reveal any information to the caller. Hang up the phone, and call your bank or credit card company using their public phone number and ask to speak to a representative to confirm what you were told.

This is by no means an exhaustive list. These are the top items in my mental checklist for validating unexpected messages I receive through any medium. When in doubt, do not trust the messenger – hang up the phone/close your browser/shut down the computer and verify what you’ve been told in a way that doesn’t rely on the information you’ve just been given.

Feel free to leave some of your own rules in the comments!

If you haven’t heard yet, Google has opened up their own public DNS servers. Many people I know would love to use them rather than their ISP’s DNS servers for various reasons – mostly due to lack of availability.

I’ve been using OpenDNS’s resolvers for the last year or so now, so this service isn’t exactly new, neither is the free option as OpenDNS has one. So what does Google bring to the table from a security perspective?

Google has a great document that they’ve created all about the security of their DNS service. Basically, they’re concerned about the availability (hence the overprovisioning), and the replay, birthday, and Kaminsky attacks. The only thing they might offer above and beyond your ISP is random ports and name server resolution. And in exchange, not only does Google get your searches, they get *every* web/e-mail/bittorrent/IRC server you go to. *put on privacy nut hat* Maybe I’m strange, but I’d prefer that Google – with their core competency as data and trends gathering – not have that much information about me.

Google has obviously considered the security implications of running public DNS servers, but is the “cost” worth it to you?

It’s been talked about in the past about how important it is to become PCI DSS compliant. For some industries it’s an absolute must. Without it, they can’t conduct business. We’ve covered some of the latest updates to PCI as well. One of the most overlooked aspects of becoming PCI DSS compliant though is actually maintaining compliance. Instead, most simply rush out to meet the requirements in order to meet the auditor deadline. Instead, we should be looking at what needs to be done on a continual basis. It’s the down time after the audit where most data breaches occur. The following list, which was put together by Dr. Anton Chuvakin, will outline the areas that require some form of upkeep.

Read the rest of this entry »