Last week, we looked at the hardening tag. Today we are going back on a specific question : Does an established SSL connection mean a line is really secure?

Why did we pick up this question? Because almost everyone has heard of SSL, but many are not sure how it works and what it is used for.

Well, the first thing we need to talk about is history of the protocol.

Secure Sockets Layer

The Secure Sockets Layer (SSL) is a cryptographic protocol – now renamed to  Transport Layer Security (or TLS). This protocol is designed to create eavesdropping-proof and tampering-proof communication over the Internet and other untrusted networks.

Originally developed by Netscape, the protocol came out in 1995 with its 2.0 version (1.0 was never publicly released). But SSL 2.0 came with some serious security flaws, which included a Man in the Middle vulnerability, which could allow an attacker to sit in the middle of an encrypted communication, unknown to either end, and decrypt the traffic. A new version was released in 1996 as SSL 3.0. The next step of the standard is SSL 3.1 also named TLS 1.0. Only a few improvements were made for this version, but enough to make TLS 1.0 and SSL 3.0 incompatible. The current version of TLS is the 1.2 release from 2008.

Applications

So what is it used for? Well many people use it on a regular basis. In fact, TLS is used on many websites to provide the HTTPS connections. But it can also encapsulate other protocols, like FTP, SMTP, NNTP or XMPP. You can even use it to secure an entire VPN as with OpenVPN.

So is it secure?

The question can’t be answered as is. It depends…

First thing to rule out is that you are not using SSL < 3.0 versions. Since they all showed flaws they should not be used now.

Secondly we must ensure the implementation is correct. This question discusses the SSL TLS Renegotiation Vulnerability which is present in some browser versions.

Next we must make sure the connection is using encryption. What? Yes: TLS supports a mode of NULL encryption.

From curiosity I’ve looked in the about:config page of Firefox 5.x. Be relieved, all ssl2 settings and null encryption mode are disabled.

And finally you need to check that the connection has been established with regard to the protocol. You may be curious on what you could have done not to respect the protocol, let me explain:

Handshaking

The connection is established in multiple steps called a handshake.

• The client connects, and if it requires a secure connection it sends a list of supported ciphers.
• The server picks a cipher from the list (Usually the first in the client list which is compatible with the server list, not necesarrily the strongest), then it notifies the client.
• The server also sends back its identification, packed into a digital certificate. This certification contains the asymmetric public key of the server and it is signed by a Certificate authority.
• The client MAY contact this Certificate Authority to confirm the validity of the server’s public key. This is very important, but the cost of online verification makes it impractical. So usually, the browser embeds Certificate Authority public key to perform an online check of the server’s certificate.
• To generate the session keys, the client encrypts a random number using the server’s public key. Asymmetric cryptography makes deciphering the number without the private key infeasible.
• Now the client and the server have a shared secret they can use to derive the keys for the actual connection.

Protocol failure

One of the key point in this scenario is the verification of the Certificate. Did you ever connect to a site and see your browser pop up a message about the certificate? Did you read the message? Usually those kind of security warning are here to tell you that the server certificate has expired, or that it is not signed by a trusted authority.

Theses warnings are critical! You may be subject to a man in the middle attack. By clicking : go to this site anyway, you are giving your browser the express command to trust the certificate you were presented. But, unless you had verified it from the Certificate Authority yourself and decided it should be trusted, you could have accepted a forged certificate by a compromised authority. Your connection is then no longer secure.

Conclusion

Does this means that respecting the protocol ensures your security? Well yes.

Provided you made all the verifications, and as AviD said in the today’s featured question:

While there are some mostly theoretical attacks on the cryptography of SSL[TLS], from my PoV its still plenty strong enough for almost all purposes, and will be for a long time.

But I should ponder that yes the connection is secure. And even if we will not turn into paranoiacs of security, one should always ask oneself what the server will be doing with the data provided. It is a good thing to send data on a secured connection, but this has no meaning if the other endpoint forwards them on unsecured lines.

To dig more:

• http://security.stackexchange.com/questions/5126/whats-the-difference-between-ssl-tls-and-https
• http://security.stackexchange.com/questions/5474/forward-secrecy-with-https-and-aes
• http://security.stackexchange.com/questions/5699/locking-down-web-based-admin-areas-with-personal-ssl-certificates

Despite the security industry getting ever more professional, with well trained teams, security incidents seem to be increasing. Just look at the news recently:

• Sony – 23 incidents so far?
• UK NHS Laptop – over 8 million patient records
• Citibank – 200,000 customer records lost
• WordPress platform vulnerabilities (see Steve Lord’s presentations on this)
• Stuxnet – targeted at a specific use

From the 2011 Verizon DBIR

• 761 breaches of which 87% were in Hospitality, Retail and Financial Services
• 436 of these were in companies with 11-100 employees – so this is not just a problem for the big targets any more
• 92% of attacks (leading to 99% of records compromised) were external

Some new threat groups:

Anonymous and LulzSec – often punitive, sometimes for the Lulz

• HBGary
• ACS Law
• Spanish Police
• FBI, CIA
• Porn sites
• Took requests

So what do the security professionals do?

• After an audit fix vulnerabilities
• After an attack, fix the issues
• Use encryption and strong authentication
• Patch regularly
• Validate input, encode output
• Assess your 3rd parties
• Use a Secure Development Lifecycle
• Build security into everything you do

No problem, right?  If only it were that easy…

Your CEO wants the business to make money, so wants to minimise bottom line spend but will spend appropriately on risks to the business.

So why doesn’t the CEO see these security issues as business risks?

• Maybe they aren’t significant when compared to other business risks
• Or perhaps the CEO just doesn’t understand the latest security threat

Both of these are your problems. The security community is often called the ‘echo chamber’ for a good reason – we say good things and have good ideas about how to fix security issues, but we pretty much only communicate with other enlightened security professionals. We need to tell others in a way they can understand – but in general we talk technical 1337 speak full of jargon and no one can make head or tail of it.

It is up to you, the security professional to learn how to talk the language of business risk

There are materials out there that will help you:

• IIA GAIT – Guide to the Assessment of IT Risk
• FAIR – Factor Analysis of Information Risk
• ISACA CobIT – Control Objectives in IT
• ISACA – CRISC and CGEIT certifications
• IISP – approved Information Risk Management courses

Begin to understand what is important to a business executive and how they talk about it, and you are already well on the way to being able to articulate security in the same way. If you are a manager of security professionals, make it easy for them to gain exposure to heads of business, C-suite, executive, directors etc. and it is likely to benefit you in the long run.

These are good questions to prepare you for conversations you may have along the way

• What metrics should a CIO rely on to gauge risk
• How would you work with the security paranoiac on your team
• Can you provide loss values on security breaches
• How do you compare risks from website, physical perimeter, staff, etc.
• What are good threats to kick off conversations with others about what worries them

Question of the Week #2

Unlike last week, where we looked at a specific question @nealmcb recommended the entire hardening tag! This is a well highlighted aspect of Information Security since it is what got many of us into the field. We knew that the factory switch config or default Windows installation wasn’t quite good enough so we tried to figure out exactly what to change in order to make things better.

From the basic Operating System hardening techniques that many of us are familiar with, we as a community have started applying the principles to more and more devices. As of writing this entry we have 19 open questions in that area ranging from What does defense in depth entail for a web app? to Best practices for securing an iPhone.

In my opinion, we’re clearly Getting It ™, as an industry, when we have moved on from Hardening Linux Server and are having real honest discussions about securing iPhones and Best practices for securing an android device.

In addition to the mobile device questions listed above, I think my favorites so far have been:

• Apache Server Hardening (Eric W)
• IIS and SQLServer Hardening (Voulnet)
• What methods are available for securing SSH? (Olivier Lalonde)
• What does defense in depth entail for a web app? (VirtuosiMedia)

While some questions have received a large amount of traffic, such as Apache Server Hardening at 9 answers and over 1000 views, others have managed to slip through with relatively little traffic, like How do I apply a security baseline to 2008 R2? slipping in at 1 answer and >200 views.

Is there a platform you use that you are not sure how to secure? Do you have experience with hardening a particular configuration? Join the party by browsing through the questions in the hardening tag and adding your own fancy tips and tricks. Better yet, ask ask ask! Show us up, or work us hard.

Question of the Week #1

How does changing your password every 90 days increase security? As selected by @HendrikBrummermann this has been one of our more popular posts, with discussion on the reasons for password expiration:

• To mitigate the problems that would occur if an attacker acquired the password hashes of your system
• It prevents people who use the same password for everything from getting your system compromised if their password is figured out somewhere else
• Compliance reduces the risk of penalties of non-compliance (thanks @AviD)
• By resetting password every X days we are telling the user – Hey, this is important and it should not be taken lightly

and Against password expiration:

• Your password, and the attacker’s guess at your password, are independent. The probability that the attacker’s next guess is correct is the same even if you change your password first.
• Nothing encourages passwords on post-its quite like frequent expiration, especially if there are also high complexity requirements
• It annoys users
• They end up having to work out a new password – which research shows is often is derived from the previous one in a way that is very easy to crack nearly half the time
• You can expect additional support costs to cover users who have forgotten

How to balance the pluses and minuses depends on your organisation’s risk profile and other requirements.

An alternative to password expirations is requiring stronger passwords, and we have questions and research on that also.

The associated question – Why do sites implement locking after 3 failed attempts – details another aspect of the defence against brute forcing, and discusses why 3 may or may not be a suitable number.

These questions, answers and commentary are well worth a read if you are trying to set a password expiry policy in your own organisation, or want some background as to the risks.

After 242 days in Beta, we now have over 3000 users and an active community of security professionals, hobbyists and specialists providing input, answers, moderation, blog posts and their own time to make the site a global success.

Congratulations to all the members – your effort has paid off, and today we joined 27 other official sites in the Stack Exchange network, and graduate as a fully fledged member. We’re excited to see the new visual design by @Jin (with comments and ideas from many of our core contributors) that permeates all aspects of the new site and blog. Various people see various things in it – the noble and powerful lion (Aslan?) on the great shield of security, wings for swiftness and protection, the various flanking maneuvers and battles raging in the background. As per the other StackExchange sites, you will even be able to get t-shirts and other logoware soon.

What does graduation mean?

A design, official inclusion into StackExchange – statistics, API tools etc. A greater presence online.

Reputation and Privileges

Private and public beta sites operate under reduced reputation requirements. This allows young sites to grow rapidly. However, when the site graduates from beta, the privilege levels return to their normal levels.

This means 19 of you have lost ‘Edit Posts’ privileges until you get over 2000, and 51 have lost ‘Vote to Close’ until you reach 3000. Don’t worry – you can always flag issues and a mod will take care of it. Once you reach the normal thresholds your privileges will automatically return.

But what is the IT Security Stack Exchange for?

From the FAQ:

IT Security – Stack Exchange is for Information Security professionals to discuss protecting assets from threats and vulnerabilities. Topics include, but are not limited to:

• web app hardening
• network security
• phishing
• risk management
• policies
• penetration testing
• security tools
• using cryptography*

Celebrate success

Let your colleagues know about the site and the blog – we already get around 1000 visits a day, but the more people who come, the wider the pool of expertise we can bring in.

We also have a twitter hashtag – #stacksecurity – so feel free to communicate to the twitterverse to let people know that answers to a lot of security questions are here.

*Also, we have just heard that a closely related site, the Cryptography Stack Exchange, has just reached 100% commit so will be entering private Beta now. While Security Stack Exchange will continue to have as one of our disciplines the understanding and management of risk in crypto implementations, here we steer clear of the mathematical issues and concentrate on security and risk.

White Hat Events is a collection of individuals from the UK’s Information Security Industry who get together to raise money for charity. The events each year include the White Hat Ball, Marathon, Golf, Cocktail Party and Rally.

The 2011 Carry-On themed White Hat Rally was fiercely fought over the weekend of 1 – 3 July, with teams from security consultancies, vendors, suppliers, and independent contractors all over the UK taking part, and raising money for and the NSPCC’s Childline, with a total raised by Sunday topping £25,000. Across the sunniest 3 days this summer we travelled from Brighton to Blackpool, following clues, competing in challenges, suffering japes, sabotage and mechanical issues, and enjoying the hospitality of towns along the way, as well as getting to know a like-minded bunch of security professionals all trying to make a difference. I joined the Northern UK Security Group (NUKSG) team in Leeds on Thursday, and we drove the Yellow Peril (an ancient Dodge Caravan bought for £350, bright yellow with an interior entirely covered in red velour) down to Brighton, where we met the other teams for a pleasant social…quite late on, due to starter motor issues, traffic, and the Yellow Peril’s lack of a top speed (among other issues)

Day one – we met up at Brighton beach, a motley collection of classic cars, sports cars, agricultural and emergency vehicles and bangers. The day involved a lovely journey across the South Downs, following clues and ending up in Cheltenham. Each team had GPS tracking apps to allow the organisers and families to see how we were doing.

At our first checkpoint stop the Pirates O’ Pentest opened up the back of their ambulance to display a fully featured and functional cocktail bar – which went down very well at each stop for the next 3 days – raising extra money for charity.

Lunch was hosted at Brooklands Museum, the birthplace of British motorsport and aviation, and included a speech by Diana Moran (the Green Goddess), who also led us in some mild aerobics, despite being in her 70’s. I was delighted to sit on the famous banking I had heard about since my early childhood, poke around the classic cars and aircraft and play on the F1 simulator.

Due to a minor organisational hiccup, The StoryTeller restaurant in Cheltenham were not made aware of the party of 67 until a couple of hours before we arrived, but they coped amazingly well – getting us all seated and providing a lovely dinner. The Scavenger Hunt in Cheltenham attracted a few entrants, but we didn’t find out the results until Sunday night.

Day two – saw us winding through the countryside up to the oldest brewery in the UK, the Three Tuns in Shropshire, for lunch, a tour of the brewery and tasting of some new brews.

We also met the lovely Clare Marie – the hostess of Dr Sketchy’s London art events. The afternoon drive then led us up to Buxton and the Palace Hotel for our evening stop. Once again we were provided with an excellent dinner, this time at the Railway, and a Carry On quiz.

Day three – a relatively short run, with some straightforward clues that got us to Blackpool, and the Big Blue hotel – which is where we were finally joined by 2 of our number we hadn’t seen for the entire event…because they cycled the entire way!! Fancy dresses were out in force, and everyone had a great time on the rollercoasters and rides before dinner (can’t believe I stayed on the Big One for 3 laps – it’s 235 feet high, one of Europ’s highest roller coasters and I’m terrified of heights!) and prizegiving at the White Tower.

Team NUKSG did not win best dressed car, best fancy dress, or prize for quiz or scavenger hunt, however we did raise the most money so we were the overall winners and took home the star prize – a bottle of the Three Tun’s Cleric’s Cure each!

We are obviously keen to keep raising money so please visit our sponsorship page. The official picture page is here at Picasa – with folders of photos from each car, as well as the Marshalls.

Many thanks again to my sponsors:

Security Stackexchange – Robert and the team provided us with sponsorship and we grabbed a couple of Stackexchange logos to stick on the car, one on each side. This went down well with the technical security folks we were competing with.

Virgin Money – Virgin’s banking department, and the providers of Virgin Money Giving – the only not-for-profit charity payments site.

Metaltech – my Rock band, preparing for new album launch party in August (@metltek and #burnyourplanet on Twitter)

According to Rory Alsop’s post the most popular topic at our IT Security site is passwords.  So in this post I’ll provide a tour of some relevant questions and answers, and a look at how it sparked further investigation of the sorry state of password protection in some current systems.

There is an amazing amount of confusion, disinformation and bad practice out there with respect to password management.  This is all the more frustrating because the basics were worked out back in the dark ages (1978 to be precise) for Unix by Bob Morris and Ken Thompson (Password Security: A Case History, Morris & Thompson, 1978). They not only covered the importance of hashing passwords with salts and a slow algorithm, but they described what is now called a “pepper” (a second salt stored apart from the password database).

So if you peruse the dozens of ‘passwords’ questions you’ll find frequent reference to the basics.  We’ve also tried to summarize some of the key points in the ‘passwords’ tag info.  By the way, that’s one of the cool things about StackExchange sites in general – how they provide for a little “wiki” for each tag, to allow us to put key information just a mouse hover or one click away from readers.

Of course even among good practitioners, there are debates about the finer points, and that is another thing you’ll find here.  See e.g. the spirited conversation about highly iterated password hashes for web apps vs the risk of DDoS attacks at Do any security experts recommend bcrypt for password storage?.

In the end, you’ll often find that the right approach depends on what kind of “security” you’re looking for.  As our Frequently Asked Questions points out, this depends on context – what assets you’re trying to protect from what sorts of threats, how your different vulnerabilities compare, and how that all fits into your business plan.

I’ll end with a look at one question which demonstrates the kind of expertise we have already attracted to the site: MySQL OLD_PASSWORD cryptanalysis?.  I asked this after stumbling across some other questions about how MySQL used to deal with passwords.  To my amazement, within hours, noted cryptographer Thomas Pornin had not only cracked the old algorithm, but he included some code to demonstrate just how totally broken the OLD_PASSWORD scheme was.  Subsequently we also found a paper from 2006 with more details.  Evidently the folks at Oracle who work on MySQL hadn’t gotten the memo then, and still have a lot of work to do to improve their current scheme, as described at Looking for example of well-known app using unsalted hashes.

So stay ahead of the crowd: when you have a question about security, see if we have a good answer.  If not, ask away.  And if you see questions that need more work, please contribute to providing good answers!

With the Security Stack Exchange site more than 6 months old now and growing fast towards graduation from a Stack Exchange Beta site, we have seen a series of trends in questions and answers, discussions and general knowledge.

Posts here over the next few months are likely to cover topics such as:

• Authentication, including password hashing, password management, password stealing, social aspects and federated alternatives like OAuth,
• Hardening of platforms and secure build
• Corporate and business aspects of security
• Cryptography – including comms, authentication, encryption, data storage etc
• Security in new environments (IPv6, Cloud, Mobile etc)

Or if you have a specific security topic you’d really like discussed, pitch it our way and we’ll get someone to have a look!

Our blog currently has a range of registered contributors from the active contributors of security.stackexchange.com but if you want to contribute, please read this post and contact one of the moderators.