Archive for May, 2006

Thunderbird 1.5 stuff – S/MIME encrustations, feed jams, and about:config

Friday, May 19th, 2006

We are working with a company that runs its own CA and issues certificates to all of its employees, and I will be receiving digitally signed and/or encrypted email messages using S/MIME from various employees there. I primarily use Thunderbird as my MUA, so I had to setup the proper certificates within Thunderbird in order to exchange encrypted and/or digital signed email messages with the employees of this company.

Now, I did not want to have to configure each certificate received for each of the company’s employee – I just wanted to import the company’s CA’s certificate in Thunderbird (version 1.5.0.x) and set that as trusted for verifying certificates for email purposes. Upon receiving my first digital signed message, I tried to pull the certificates included with the S/MIME digital signature (PKCS#7 format) into Thunderbird, but there was no clear way to do so – I could view the signer’s certificate and the signature itself, but I did not see any way to pull the signer’s certificate directly into Thunderbird and configure for what purposes I trusted that certificate. More importantly for my goal, there was no way to even view the CA certificate included with the signature through Thunderbird.

So, I ended up doing the following to extract the CA certificate included with the S/MIME digital signature and import the CA certificate into Thunderbird.

  • In Thunderbird, viewed the source of the email message containing the signature (Open message and View->Message Source).
  • In Thunderbird, select and copied the contents of the signature (the MIME part of Content-Type: application/x-pkcs7-signature) from the message source.
  • In favorite editor, pasted this into a text file that I named smime.p7s.
  • On Windows, opened this file using the Certificates snap-in for MMC, which allowed browsing of the certificates contained within the S/MIME digital signature blob and exporting them. (To install the Certificates snap-in, Start->Run and type in “mmc” in the text box and hit enter. In MMC, go to File->Add/Remove Snap-in->Add->Certificates.)
  • Using the Certificates snap-in, exported the CA’s certificate as a DER-encoded binary X.509 (Right click on the certificate, All Tasks->Export and follow the dialog)
  • Back in Thunderbird, imported this into Thunderbirds certificate store (Tools->Options->Privacy->Security->View Certificates->Authorities->Import and follow the dialog).

Important note: If you have the Enigmail plugin set to Automatically Decrypt/Verify Messages, then it could conflict with the builtin S/MIME functionality of Thunderbird. I recommend unchecking that option (OpenPGP->Automatic Decrypt/Verify Messages).

After importing the CA certificate and trusting it for email purposes, Thunderbird then automatically pulled end user certificates issued by that CA into its store from digital signed email messages.

(For some reason, I feel there has to be an easier way to accomplish this. Please feel free to comment.)

-

Setting up my own certificates for S/MIME was quite a bit easier. To import my key pair (PKCS#12 format), select Tools->Options->Privacy->Security->View Certificates->Your Certificates->Import and follow the dialog. Then, to setup S/MIME for a particular account, Tools->Accounts-><select account and expand options>->Security and select the appriopriate certificates for digital signatures and encryption.

-

Every once in a while, one of my Thunderbird accounts for feeds stops updating the various subscribed feeds with new posts. Courtesy of this thread, to fix this problem, I exited Thunderbird and removed the “feeditems.rdf” file (I did not need to remove “feeds.rdf”) from the directory where Thunderbird stored the information for that troublesome feed account (the appropriate directory was somewhere like “<Profile Location>/Mail/News & Blogs-<index number>”.) Upon restarting Thunderbird, the subscribed feeds updated again.

-

The best reference for the advanced configuration options (i.e., about:config) in Thunderbird (and Firefox) that I have found is here, although the list of settings is incomplete (at least, for Thunderbird 1.5), so you may still have to search around for more information. Also note, the Firefox settings are distinct from the Thunderbird settings, so changes like those described here for Firefox will not be automatically applied to Thunderbird.

Posted in Crypto, Security | 3 Comments »

Move

Wednesday, May 17th, 2006

Many people noticed the blog outtage that kicked in fully by Monday. I finally gave up the ghost, and D-kriptik has switched hosting providers. I was sad to make the move, but it seemed necessary.

So, here we are at aplus.net. May it serve us well.

(kriptik.org, which is personal, is still over at our previous hosting provider for the time being. I couldn’t pull all the bandaids off so quickly. ;) )

Posted in D-Kriptik | No Comments »

Email to blog exception filter

Thursday, May 11th, 2006

Someone asked me me about my email to blog rules, so here goes.

In general, anything you send me (Andrew Donofrio) via email is considered to be fair game for this blog assuming it is relevant to the blog; however, I do run such content through the following filter.

  1. Any information in an email message that I consider to be sensitive is considered private and not for the blog. Those that know me know that my definition of sensitive is quite conservative, which means it covers a wider range of information than most people I know consider to be sensitive. This includes virtually all customer specific information.
  2. Any portion of an email message that is encrypted to me is considered private and not for the blog. Yes, that applies to the few of you that exchange only encrypted email messages with me, although, more often than not, the content is not at all sensitive. No, that does not mean your mail server establishing an encrypted session with our (hosting provider’s) mail server.
  3. Any email message that contains rules for how its content should be covered in the blog has those rules respected, from stating not to blog about it to asking that only its origins remain anonymous.
  4. Any information in an email message covered by an NDA (or other contractual restrictions that prevent dissemination) to which I am legally bound is considered private and not for the blog. This is just a given.

You can use 2-4 to avoid the subjective nature of 1, but 1 tends to be more than enough for just about everyone.

Posted in Off-topic | 1 Comment »

Recent CC discussion

Tuesday, May 9th, 2006

Someone asked for my thoughts about this article and the resulting blog posts (the ones I know of are 1,2,3 at Appex Assurance, and 1 at TaoSecurity) on Common Criteria (CC). Now, the Apex Assurance guys, to abuse a phrase, have forgotten more about the CC than I will ever know; however, here is my short, uninformed opinion.

From here…

It sounds like Common Criteria is becoming nothing but a hurdle to keep smaller companies from providing products to government agencies.

And here…

Perhaps Mr. Pescatore isn’t familiar with the Federal Acquisition Regulations, but blatant favoritism is a no-no. I also don’t really think that he thought this one through. How can NIAP possibly provide evaluation subsidies when they can’t even afford enough validators?

Furthermore, why not provide subsidies to large vendors when they are unfairly forced to pursue Common Criteria? Here’s what I mean by unfairly: in my days at Cisco, especially the early ones, we were seeing requirements from Common Criteria when our competitors weren’t.[...]

I heard something to this effect in a conversation I was having with someone that worked for a government agency. They told me that they liked CC because it kept the number of applicable responses to RFPs very small and it could be used to focus in on preferred vendors.

From here…

I think that what Mr. Pescatore was trying to say was that there has been some attrition in the validation community, and NIAP is having trouble replacing the resources because of funding and lack of, well, talent – the pool of validators is small, and the pool of senior validators is even smaller. This has nothing to do with EAL5-7 testing. That level of evaluation will always take a long time because of the rigor involved. Plus, look at the In-evaluation list and the Validated Products List: there aren’t many EAL5-7 evaluations. That’s not what’s slowing the process.

The CC community, and NIAP in particular, is built from communities like TCSEC that preceded it and agencies like the NSA. Even just looking at the ties to the intelligence community and classified environments, it is obvious the CC community is very closed. (I remember NIAP being a joint effort between NSA and NIST. Then, NIST was pushed out.) And, the work tends to be dry, with a focus on language and process more than anything. (As a buddy of mine says, a good chunk of the work is “validating that every t is crossed and every i is dotted.”) That makes it hard to bring in new blood.

Now, the NSA loves assurance. The NSA does not really care about the customers of these certifications, whether vendors or agencies – their focus is on national security. Anybody that has gone through an NSA certification knows exactly what I mean. And, in the USA, I think the CC process has grown to feel a bit more like the NSA certification process over the last few years – perhaps now is the time to reverse that trend for lower EALs (1-4).

My take, bring NIST back into the equation and use them to help open up CC a bit more in the USA – of course, the logistics of getting them all to play nice together is the hard part.

So, how wrong am I?

Posted in Off-topic | 1 Comment »

Upcoming NYCBUG meeting (May 2006)

Wednesday, May 3rd, 2006

The next NYCBUG meeting is tonight (May 03, 2006) from 6:30-8PM EST. Using OpenBSD to build VPNs for large enterprises sounds really interesting to me, although I would like to hear the discussion on PAE for OpenBSD as well. And, the venue has changed to a bar. Good stuff.

May 03, 2006
Mischa Diehm: VPN & Mickey Shalayeff: PAE
[...]

Suspenders Bar
6:30 PM to 8:00 PM
111 Broadway & Thames
directions are here

Part 1: VPNs with OpenBSD in large corporate networks

[...]This talk will show different practical approaches in building flexible secure VPNs with OpenBSD at different network levels.
[...]

Part 2: Implementing PAE for OpenBSD/i386

Not yet committed to OpenBSD, Mickey has been working on PAE for OpenBSD i386. Essentially, it`s about supporting up to 64 gig of physical memory.

Also, the next Dorkbot-nyc meeting is happening tonight (May 03, 2006) at Location One from 7-9PM EST. Here is the flyer.

Unfortunately, I will not be able to attend the NYCBUG (or dorkbot-nyc) meetings tonight. If anyone does attend and wants to do a brief write-up, please let me know – full credit will be given, and we receive a decent amount of traffic to our meeting write-ups, especially the NYCBUG ones. Thanks.

Posted in Conferences, NYCBUG | No Comments »

Reminded of bookmarks & fingerprints

Wednesday, May 3rd, 2006

I enjoyed this post on Emergent Chaos.

So, I’d love to hear why, in an era when criminal enterprises are able to forge an entire enterprise, to the extent of developing new products, they won’t do enough to get a high assurance certificate?

True.

Shostak proposed the following solution.

I expect that persistence memory about the certificate, so that your browser alerts you on change, with a design that has been created with the user in mind, and tested on a variety of real users, is the right model.

This brought to mind a few notes from this post on D-kriptik, as excerpted below.

[...]For example, you could establish an SSL/TLS session with a malicious web site that has a domain name that is a variation of, or related to, the name of the site you intended to visit. That site could easily have a proper certificate signed by a browser trusted authority for that domain name, which means the browser does not even pop up a warning dialog box.

(We already see lots of business web sites that use separate payment providers, so when a user goes to checkout, they get redirected to some random payment web site. And, I was recently complaining to someone about bank web sites that have bizarre domains, a couple of which use variations of their normal domain for their online banking. So, people have become accustomed to entering sensitive information under “weird” domains.)

I think this attack will apply regardless of “high assurance” certificates. As Shostak pointed out, getting “high assurance” certificates can make sense for attackers.

In fact, most people have no idea what warning dialogs with relation to SSL/TLS negotiations or digital certificates mean, and, in many cases, they are false alarms anyway. So, virtually everyone has grown accustomed to just clicking through such warning dialogs.[...]

Attacks based on user ignorance of anything to do with PKI or TLS will apply regardless of “high assurance” certificates or not. What really matters here is whether or not browser security indicators matter to users (e.g., do users know about the security indicators provided by a browser, what the indicators mean, and what should be done in response to the indicators?).

[...]verifying that you are in fact establishing an SSL/TLS session with the proper entity.[...]

[...]countering an SSL/TLS MITM attack.[...]

This is an active research area. Petnames have been proposed, which I like (think PGP web of trust in some form). This has similarities to the SSH-type trust model, which has also been proposed and which I also like. In recent minutes to an IETF-PKIX meeting, the Opera people were looking at “extended validation” certificates. There has been all sorts of talk, pros and cons, about “high-assurance” certificates.

In this regard, while I like the idea of bookmarking a web site and its certificate(s), how exactly to inform a user that a certificate is changed, and establishing what actions a user should take in such a case, is the hard part. Every model I envision reduces to checking the digital certificates when the certificate presented is different from the one that is bookmarked, and then all the same problems come back into play – you might as well have just bookmarked the web site and left out the certificate.

Which leads me to what I have quoted a few times from this post.

Bookmark web sites that you visit, especially where you conduct transactions like buying stuff, and then return to those sites only through your bookmarks (this is like what we do with server public keys in SSH). Now, when you receive that email, instant message, or embedded link in some rogue web site purporting to be from, or purporting to point you to, Paypal and you really do feel it necessary to log into Paypal in response, don’t follow any of the links provided – instead, use your bookmark for the Paypal web site. It doesn’t solve all these problems, but it helps quite a bit.

Combine that with a broader version of something like PwdHash or, better yet, throw in widespread deployment of TLS with pre-shared keys (PSKs) (RFC 4279), and there you go.

-

I noticed this paper.

We develop and evaluate a system we call Loud-and-Clear (L&C) which places very little demand on the human user. L&C involves the use of a text-to-speech (TTS) engine for vocalizing a robust-sounding and syntactically-correct (English-like) sentence derived from the hash of a device’s public key. By coupling vocalization on one device with the display of the same information on another device, we demonstrate that L&C is suitable for secure device pairing (e.g., key exchange) and similar tasks.

This reminds me of one of the ways people (including myself) perform remote, (somewhat) out of band verification of each other’s OpenPGP public keys during an initial exchange of those keys over, say, the Internet.

The general idea is that I send my OpenPGP public key to my buddy via, say, email. Now, my buddy has no way of knowing whether the key received via email is actually from me – for example, someone else could have sent them a OpenPGP public key and claimed it was from me, or someone could be sitting in between us and replaced my key with their own. So, I call my buddy (or vice versa) and read off the key’s fingerprint while my buddy verifies that the key received has that fingerprint, usually by visually matching what I am reading off.

Of course, we don’t use Mad Libs, but some OpenPGP applications do translate the fingerprint into a string of words, instead of just displaying it in raw hex. Whatever floats your boat.

Posted in Authentication & Identity, Security | 2 Comments »

Look RFCs 4346 & 4347, info overload

Tuesday, May 2nd, 2006

TLS is one of the most important cryptographic protocols out there today. It is being used for everything from simple wrapping of HTTP and SMTP to full-blown VPNs. So, I took note of the official release of RFC 4346, which specifies TLSv1.1.

The main differences between v1.0 (RFC 2246) and v1.1, as excerpted from RFC 4346.

– The implicit Initialization Vector (IV) is replaced with an
explicit IV to protect against CBC attacks [CBCATT].

– Handling of padding errors is changed to use the bad_record_mac
alert rather than the decryption_failed alert to protect against
CBC attacks.

– IANA registries are defined for protocol parameters.

– Premature closes no longer cause a session to be nonresumable.

– Additional informational notes were added for various new attacks
on TLS.

Security design tweaks aside, I really enjoyed the “Informative References” section at the end of the RFC – it includes a paper I really enjoyed a few years ago (I know, I bugged many of you to read that back then) and a great overview of how some practical attacks on SSL/TLS (when used with block ciphers in CBC mode) were mitigated in OpenSSL. (An interesting note – OpenSSL already had workarounds for attacks that now have specific countermeasures in TLSv1.1, so the RFC is essentially catching up with the implementation reality in this regard, at least for the large user base of OpenSSL.)

Also, RFC 4347, specifying DTLS, is now officially out there. DTLS is based on TLS, but, while TLS requires a reliable transport layer, DTLS assumes an unreliable transport layer. This can be useful for things like VoIP, where one may not care if all of their traffic gets through, just enough of it that they can understand the voice conversation being communicated.

On a side note, I brought this up to someone, and they asked, “Reliable tranport? Unreliable transport? What does that mean?” Well, lets look at the particular example of UDP versus TCP as discussed in the Introduction section of TCP/IP Illustrated, Volume 1.

In the TCP/IP protocol suite there are two vastly different transport protocols: TCP (Transmission Control Protocol) and UDP (User Datagram Protocol).

TCP provides a reliable flow of data between two hosts. It is concerned with things such as dividing the data passed to it from the application into appropriately sized chunks for the network layer below, acknowledging received packets, setting timeouts to make certain the other end acknowledges packets that are sent, and so on. Because this reliable flow of data is provided by the transport layer, the application layer can ignore all these details.

UDP, on the other hand, provides a much simpler service to the application layer. It just sends packets of data called datagrams from one host to the other, but there is no guarantee that the datagrams reach the other end. Any desired reliability must be added by the application layer.

There is a use for each type of transport protocol, which we’ll see when we look at the different applications that use TCP and UDP.

Anyway, I am not sure whether basic networking concepts need to be understood before diving into the RFCs for TLSv1.1 and DTLS. I tend to think not.

Update: “Isn’t TLS 1.0 just SSL 3.0?” No, there are minor differences between the two, which, among other things, is why TLSv1.0 is allowed for FIPS 140-1/2 and SSLv3.0 is not (I wrote a tiny white paper on this back a few years ago). Within the SSL/TLS protocol itself, SSLv3.0 is identified as version 3.0, TLSv1.0 is identified as version 3.1, and TLSv1.1 is identified as version 3.2.

“Isn’t there TLS 1.2?” There will be – TLSv1.2 is under development, and it’s main focus is on hash algorithm agility and adding new cipher suites. The IETF working group for TLS can be found here, and the current draft for TLSv1.2 can be found here. If you are interested in the future of TLS, I recommend joining the working group’s mailing list.

-

I read the “The myth of “keeping up”” post over at Creating Passionate Users. To summarize, information overload can be a problem, so limit your sources, use concise relays, and find helpers.

(Disclosure: I am an information pack rat, even with hard copies.)

These two great points from the post combine to be the key to handling this issue in an everyday sort of capacity.

Find the best aggregators

Get summaries

The recommendation of finding good aggregators is key – use a few noteworthy blogs, link aggregators, and mailing lists to distill down the information out there to a manageable level. By looking at archives of such a person/service or following their content for a period of time, you can determine who/what highlights information that is most important to you in a way that works for you. And, good aggregators of information include useful summaries, which is important to allowing you to quickly filter through content.

Then there is this.

Cut the redundancy!

Unsubscribe to as many things as possible

I disagree with these points in regards to soft copies of information. Storage is cheap, and, while there is certainly no need to read every mailing list post, every technical article, every paper, etc., storing that information for later search and retrieval is quite important, especially with how quickly some things seem to disappear from the online world or how hard it can be to find something again with all that is out there. I know I have many feed and mailing list subscriptions that I do not read regularly, but which I dig through when trying to find more information on a particular topic – the clips mailing list is a good example of this.

Hard copies are harder to deal with – they generally use more expensive resources and are harder to search – so I think the advice of maintaining a core subscription base could hold here, perhaps revolving around those things that are commonly of great interest to you or those things that are harder to find online. The good news here, most hard copy publications are now providing soft copies as well, and, for those that don’t and legacy publications, searchable repositories (like this) can be used to find references to content that you have in hard copy, effectively pulling search functionality into your hard copies. (Come on, who out there doesn’t have a stack of ancient manuals lying around? :) )

In the meantime, take a deep breath and repeat after me, “I will never keep up. Keeping up is a myth.” And if it makes you feel any better, add, “John isn’t keeping up either.”

Better yet, realize technology is there to help you, not hurt you. Read a little, skim some more, and skip most – but, archive all, and then forget about it until needed.

Posted in Off-topic, Security | No Comments »