Encryption

REVIEW: “SSL and TLS: Theory and Practice”, Rolf Oppliger

BKSSLTTP.RVW   20091129

“SSL and TLS: Theory and Practice”, Rolf Oppliger, 2009, 978-1-59693-447-4
%A   Rolf Oppliger rolf.oppliger@esecurity.ch
%C   685 Canton St., Norwood, MA   02062
%D   2009
%G   978-1-59693-447-4 1-59693-447-6
%I   Artech House/Horizon
%O   617-769-9750 800-225-9977 artech@artech-house.com
%O   http://books.esecurity.ch/ssltls.html
%O  http://www.amazon.com/exec/obidos/ASIN/1596934476/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1596934476/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1596934476/robsladesin03-20
%O   Audience i+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P   257 p.
%T   “SSL and TLS: Theory and Practice”

The preface states that the book is intended to update the existing literature on SSL (Secure Sockets Layer) and TLS (Transport Layer Security), and to provide a design level understanding of the protocols.  (Oppliger does not address issues of implementation or specific products.)  The work assumes a basic understanding of TCP/IP, the Internet standards process, and cryptography, altough some fundamental cryptographic principles are given.

Chapter one is a basic introduction to security and some related concepts.  The author uses the definition of security architecture from RFC 2828 to provide a useful starting point and analogy.  The five security services listed in ISO 7498-2 and X.800 (authentication, access control, confidentiality, integrity, and nonrepudiation) are clearly defined, and the resultant specific and pervasive security mechanisms are mentioned.  In chapter two, Oppliger gives a brief overview of a number of cryptologic terms and concepts, but some (such as steganography) may not be relevant to examination of the SSL and TLS protocols.  (There is also a slight conflict: in chapter one, a secure system is defined as one that is proof against a specific and defined threat, whereas, in chapter two, this is seen as conditional security.)  The author’s commentary is, as in all his works, clear and insightful, but the cryptographic theory provided does go well beyond what is required for this topic.

Chapter three, although entitled “Transport Layer Security,” is basically a history of both SSL and TLS.  SSL is examined in terms of the protocols, structures, and messages, in chapter four.  There is also a quick analysis of the structural strength of the specification.
Since TLS is derived from SSL, the material in chapter five concentrates on the differences between SSL 3.0 and TLS 1.0, and then looks at algorithmic options for TLS 1.1 and 1.2.  DTLS (Datagram Transport Layer Security), for UDP (User Datagram Protocol), is described briefly in chapter six, and seems to simply add sequence numbers to UDP, with some additional provision for security cookie exchanges.  Chapter seven notes the use of SSL for VPN (virtual private network) tunneling.  Chapter eight reviews some aspects of
public key certificates, but provides little background for full implementation of PKI (Public Key Infrastructure).  As a finishing touch, chapter nine notes the sidejacking attacks, concerns about man-in-the-middle (MITM) attacks (quite germane, at the moment), and notes that we should move from certificate based PKI to a trust and privilege management infrastructure (PMI).

In relatively few pages, Oppliger has provided background, introduction, and technical details of the SSL and TLS variants you are likely to encounter.  The material is clear, well structured, and easily accessible.  He has definitely enhanced the literature, not only of TLS, but also of security in general.

copyright Robert M. Slade, 2009    BKSSLTTP.RVW   20091129

Why a 27 character password is less secure than an 8 character one

The Russians obviously did not read my earlier posts on why longer passwords are often less secure than shorter ones.
So they forced their agents to use a 27-character password which was easily retrieved by the FBI… since it was written on a piece of paper.

The time it takes to break a 27-character password: a few hours (going through the post-it notes and paper scraps)
The time it takes to break an 8-character password: 242 Days (assuming uppercase/lowercase letters only, brute forcing 10,000 passwords per second).

(via Bruce Schneier. Password recovery calculation time here)

Examining malware will be illegal in Canada

We’ve got a new law coming up in Canada: C-32, otherwise known as DMCA-lite.

Lemme quote you a section:

29.22 (1) It is not an infringement of copyright for an individual to reproduce a work or other subject-matter or any substantial part of a work or other subject-matter if
[…]
(c) the individual, in order to make the reproduction, did not circumvent, as defined in section 41, a technological protection measure, as defined in that section, or cause one to be circumvented.

Now, of course, if you want to examine a virus, or other malware, you have to make a copy, right?  So, if the virus writer has obfuscated the code, say by doing a little simple encryption, obviously he was trying to use a “technological protection measure, as defined in that section,” right?  So, decrypting the file is illegal.

Of course, it’s been illegal in the US for some years, now …

 
 
 

The complexity of the ad-hoc network (and network research)

After months of intermittent attempts and research, I finally have a connection between two of my laptops, and an Internet connection to the one that is not physically connected to the wired LAN.

(Well, perhaps I might qualify that.  I appear to have a connection to the Internet, and I seem to have been successful at viewing a couple of Websites, and sending one piece of email.  It’s pig slow, and at the moment the mailer is trying to download some email.  It’s made enough of a connection to know that some email is there, but actually retrieving the email is taking enough time that I have been able to start to prep this posting in a browser window while I’m waiting.  I type very slowly, and, as of the end of this paragraph, it hasn’t yet successfully downloaded the second of seven messages.)

(The speed of the connection [although the computer says the connection is “Very Good”] may be due to the fact that I’m using  WEP with 104, rather than 40, bit key.  Don’t know how much difference it would make.  At the moment, having only just established the connection, I’m not about to mess with the settings to find out.)

However, as happy as I am to have the connection, the simple fact of it is not important enough to warrant a blog post.  No, the real point is all the trouble I encountered trying to find out how to make it work.  Following on from the complexity of any computing that I wrote about earlier.
As usual, I made my own life more difficult.  If all I wanted was a simple ad-hoc wireless network, that could be had for the asking.  Well, sort of.  A simple wireless network doesn’t do very much, unless you can share information from the drives, or share an Internet connection.  And that seems to be extra.

(Maybe.  At one point in the process, I had left one of the test wireless networks “on.”  And in one of my classes, one of my students managed to connect to it and get an Internet connection from the wired connection I had.  Random successes aren’t terribly useful, unless you can repeat them.)

Anyway, I have a wired network at home.  I have sharing enabled, so that I can copy materials from one machine to another.  At the moment, all of them run Windows XP.  (Yeah, I know.  I’ll get around to Linux sometime …)  I have (now) multiple laptops, and have to take at least one of them on the road for teaching.  And, of course, the mobile machines have to connect to all kinds of wired and wireless connections on the road.

Of course, the easy way would be to go to London Drugs and get a wireless router, connect it to the wired LAN, and fill in a few simple settings.  It’d probably take no more than a couple of hours, from beginning to end.  But I wouldn’t learn much about ad-hoc networking that way, and I’ve been getting more interested in it, particularly as a security concern, as I have been seeing that “computer-to-computer network” legend show up in more and more places.  (Especially with “Free Internet Connection!” as the network name.)

So, having a spare laptop (since, on a recent teaching trip, it decided to go spare on me), I figured it would be easy to set up a connection between that and the new one.

Actually, it was on the trip that I wanted to start the process.  There was nothing wrong with the old laptop (except that it was a Toshiba, and I’ve had two Toshibas in a row, and I will never again by anything made by Toshiba since they’ve given me nothing but grief for eight years) except that the power supply was becoming unreliable.  I bought a cheap (and non-Toshiba) netbook and asked for advice about connecting them via ad-hoc network in order to transfer the necessary files.

Well, lots of advice, but nothing actually worked, and I fell back on using the Passport external drive my wonderful daughters gave me that has been so useful in so many situations.  But it doesn’t do networking.

The friends gave me some starting points in terms of places to look for advice.  Microsoft, naturally.  There is a wonderful page at http://www.microsoft.com/windowsxp/using/networking/expert/bowman_02april08.mspx which provides clear explanations.  Only a couple of problems: it was written in 2002, so the dialogue boxes have changed.  This piece does talk about sharing an Internet connection, but it doesn’t mention the need to modify the default IP addresses, since everything seems to want to use 192.168.0.1 as a base, and that leads to conflicts.  Bottom line: it doesn’t work.

Microsoft updated the information in 2006 at http://www.microsoft.com/windowsxp/using/networking/setup/adhoc.mspx and the dialogue boxes are closer to what you’ll actually see these days.  After running through that one I tested it out, only to find that the network never does show up on “Available Wireless Networks.”  I’m not sure if this is because, if you choose WEP, and tell it not to broadcast the key, it keeps it hidden.  I did manage to connect to the network, and even seemed to be able to see other computers drives, and see something of the Internet, but all of the connections disappeared over time.  Again, this page says to use Internet Connection Sharing, but doesn’t provide the necessary detail to make it work.

All kinds of pages are out there, if you do a Web search, seemingly based on this same, limited, misinformation.  At http://www.home-network-help.com/ad-hoc-wireless-network.html the author seems to have given some thought to the issue of IP addresses, but not much.  http://www.home-network-help.com/ics-host-computer.html goes into a bit more detail on the IP addresses, but not enough, particularly in terms of the entries that have to be made in various places on various machines.

Finding all the places to make those entries is a trip in and of itself.  The Help and Support Center for XP Home Edition is no help.  At one point I was afraid that the multitude of entries for the various networks I’ve connected to in hotels, airports, and seminar hosting sites had something to do with it, so I went and deleted all of those “Preferred networks” I had accumulated over the years.  (Did you know that they were all still there?)

Lots of people are willing, and more than willing, to provide the benefit of their lack of experience.  I say this, since so many of the entries don’t actually work.  http://www.ehow.com/how_6108229_make-wirelss-internet-_ad_hoc-wireless_.html  Terse, doesn’t work.  http://www.ehow.com/how_5167281_create-ad-hoc-wifi-network.html  Slight tech detail, doesn’t cover sharing drive or Internet connection, doesn’t explain how to make new wireless network visible to “View available wireless networks.”  http://www.ehow.com/how_5154137_create-ad-hoc-network.html  A touch more detail than above (5167281), mentions need to share Internet connection, mentions a dialogue button that doesn’t exist in the XP explanation.  http://www.ehow.com/how_5946176_set-hoc-network-windows-xp.html  Some detail on setting up the network, doesn’t completely work, nothing on sharing.  http://www.ehow.com/way_5492555_ad-hoc-network-tutorial.html  Some detail on setting up the network, doesn’t completely work, nothing on sharing.  http://www.ehow.com/how_5670567_set-ad-hoc-wireless-network.html  Some detail on setting up the network, doesn’t completely work, nothing on sharing, does do XP and Vista.

Some of the advice is contradictory.  For example, I mentioned I was using WEP.  This is because some of the sites, such as http://www.hardwaresecrets.com/article/418 and http://www.tomshardware.com/forum/28615-42-networking-security-problem suggest that WPA and WPA2 can’t be used if the “host” for your ad-hoc network is running Windows XP (which mine is).  Of course, that might be old news, which might have been superceded by intervening upgrades.  But, with this level of information, how am I supposed to tell?

We are awash in a sea of information.  Except that some of the information is misinformative.  As John Lawton stated, the irony of the information Age is that it has given new respectability to uninformed opinion.  This can have rather significant consequences.  A recent CBC story notes that this may play into the May 6 stock market mini-meltdown.

So far, the best clue I received was from http://www.wi-fiplanet.com/tutorials/article.php/3822651  I had frequently seen the “Bridge connections” option, but I somehow never thought to have two networks “selected” when I tried it.  Even then, I might have missed the opportunity.  I got the usual error message, but it suddenly dawned on me that ICS might conflict with it.  (Given that everybody else had been telling me to turn ICS on.)  So, I turned ICS off, and, sure enough, Bridge connections was happy to do just that.

I still have no clue what has been set, and where …

Vanishingly small utility …

This system has had some discussion in the forensics world over the past few days.  Here’s an extract from Science Daily:

“Computers have made it virtually impossible to leave the past behind. College Facebook posts or pictures can resurface during a job interview. A lost cell phone can expose personal photos or text messages. A legal investigation can subpoena the entire contents of a home or work computer. The University of Washington has developed a way to make such information expire. After a set time period, electronic communications such as e-mail, Facebook posts and chat messages would automatically self-destruct, becoming irretrievable from all Web sites, inboxes, outboxes, backup sites and home computers. Not even the sender could retrieve them.

“The team of UW computer scientists developed a prototype system called Vanish that can place a time limit on text uploaded to any Web service through a Web browser.

[Perhaps a bit narrower focus than the original promise, but it is a prototype – rms]

“After a set time text written using Vanish will, in essence, self-destruct.  The Vanish prototype washes away data using the natural turnover, called “churn,” on large file-sharing systems known as peer-to-peer networks. For each message that it sends, Vanish creates a secret key, which it never reveals to the user, and then encrypts the message with that key. It then divides the key into dozens of pieces and sprinkles those pieces on random computers that belong to worldwide file-sharing networks. The file-sharing system constantly changes as computers join or leave the network, meaning that over time parts of the key become permanently inaccessible. Once enough key parts are lost, the original message can no longer be deciphered.”

However, given the promise to clean up social networking sites, and as I started to read the paper, an immediate problem occurred to me.  And, lo and hehold, the authors admit it:

“We therefore focus our threat model and subsequent analyses on attackers who wish to compromise data privacy. Two key properties of our threat model are:
1. Trusted data owners. Users with legitimate access to the same VDOs trust each other.
2. Retroactive attacks on privacy. Attackers do not know which VDOs they wish to access until after the VDOs expire.
The former aspect of the threat model is straightforward, and in fact is a shared assumption with traditional encryption schemes: it would be impossible for our system to protect against a user who chooses to leak or permanently preserve the cleartext contents of a VDO-encapsulated file through out-of-band means. For example, if Ann sends Carla a VDO-encapsulated email, Ann must trust Carla not to print and store a hard-copy of the email in cleartext.”

So, this system works perfectly.  If you only communicate with people you trust (both in terms of intent, and competence), and who only use the system properly, and never use any of the information in any program that is not part of the system, it’s completely secure.

How often have we heard that said?

The default to privacy aspect is interesting, and the automatic transparency for the user as well, but this simply moves the problem one step back, as it were.  In terms of utility to social networking, the social networks would have to be completely rewritten to adher to the system, and even then it would be pretty much impossible to ensure that nobody would have the ability to scrape data and keep or publish it elsewhere.

(Plus, the data is still there, and so is Moore’s Law …)

The oldest vulnerability is known – let’s find the oldest data loss incident

The oldest documented vulnerability in computer security world is password file disclosure vulnerability from 1965, found by Mr. Ryan Russell.

Open Security Foundation – an organization behind OSVDB and DataLossDB has launched a competition to find the oldest documented data loss incident.

The last day to make a submission is next Friday – 15th May.
The link is easy to remember – datalossdb.org/oldest_incidents_contest.