New version of XPath XML editor

Recently I needed to use my XPath XML editor to tweak a number of POMs. Only catch was that I was required to do this on a Windows machine.

What's the catch you ask? XML and Java work just as fine on Windows. However, my editor requires a list of POM file names on the command line, something I quite easily fixed with

`find . -name pom.xml`

This isn't easy in CMD, but even Windows has evolved recently. Enter Windows PowerShell. The PowerShell replacement is pretty simple once you get to know the PowerShell basics:

$(ls -include pom.xml -recurse -name)

If you'd like to tinker with it, I've also pushed the xmleditor to GitHub.

Six questions on TDD

Read Uncle Bob's TDD Triage:

"Is TDD a replacement for architecture?

Is TDD a replacement for design?

Should TDD be used for every line of code?

Well, if you are going to write some tests afterwards, why not write all tests afterwards?

Given that we accept the need for tests, why the resistance to test-first?

Wouldn’t it be faster without such high test coverage?"

and Echoes from the Stone Age:

"TDD

The Design Pattern Religion

Minimizing Concurrency"

Very good reads indeed. It is of course triggered by all the controversy of Joel Spolsky's blog on Jamie Zawinski being a Duct Tape Programmer.

Here are some of my comments:

1. Learn concurrency principles. You'll need it. Moore's Law no longer gives you more clock cycles per second, it gives you more processor cores. To effectively utilize a modern CPU you have to keep all cores busy. And if you struggle keeping two quad-cores busy, imagine keeping 1,000 cores busy. It probably requires a fundamental programming paradigm change like the proposed fork-join framework for Java.
2. Use high level building blocks like java.util.concurrent and java.util.concurrent.atomic. It gives you well tested code that is maintained by Other Smart People, relieving your brain to work on more important things. Two classes to study: ExecutorService and BlockingQueue.
3. TDD is a good way of writing safe concurrency code. Design each element as a single threaded execution flow, and assert state before and after. Pay attention to locks and shared data.
4. Architecture is Important. You don't build a skyscraper or a space station in the same way as a dog house or a residential house.
5. Testing is a good way of exploring unknown APIs or legacy code. You basically assert the expected output or behavior of the code you are exploring.
6. Duct Tape is good for many things. You can even build a sailboat out of it. But you probably wouldn't enlist for the Volvo Ocean Race with it?

Versions Maven Plugin

Ever struggled with keeping versions of dependencies or inter-module links up to date? Now the Versions Maven Plugin comes to the rescue! It has readily available goals for tasks like:

• Advancing dependency versions
• Updating the Parent version
• Fixing a multi-module build
• Changing the project version
• Locking snapshot dependencies
• Replacing -SNAPSHOT versions with their corresponding releases

The worst thing about this plugin is that it haven't appeared sooner. It also means I can now retire my XML Editor tool's primary usage.

HTTPS connection explained

If you wonder how HTTPS works, you could read this one:

The First Few Milliseconds of an HTTPS Connection

After that, please come back and read my post TLS: A Broken Trust Model about the flaws of how HTTPS establishes a trust relationship between client and server.

To glade turjenter

Tur til trestiklevann

TLS: A Broken Trust Model

What is TLS

TLS stands for Transport Layer Security. It was formerly known as SSL, or Secure Sockets Layer. In short, it's the protocol behind the s in https, making internet banking, passwords and other data safe from eavesdropping while browsing.

In https, TLS also has another purpose -- trust. Through a chain of digital certificates and certificate authorities, the system tries to ensure you that the web site you are visiting is controlled by the company they claim to be.

How Does TLS Work

To protect communication, an encryption key has to be agreed upon by both ends in the conversation - namely the web browser and the web server. Because of efficiency this key must be identical on both sides. But how do you exchange this key in a secure fashion, ensuring no-one else can access it?

TLS solves this by encoding this key in another key. This other key is asymmetric, meaning different keys are used for encrypting and decrypting data. The key used for encrypting data can thus be openly exchanged. This encryption key, also called the public key, is encapsulated in a digital certificate with other information about the rightful owner of this key.

Among other things, this certificate contains the DNS name of the web server who owns it, and the name of the organization or individual it is registered to.

This certificate is presented to the browser by the web server when they initiate the TLS session.

The Purpose of those Certificates

But how do you know that this certificate is valid? This is where certificate authorities come in. They sign digital certificates, telling us that they vouch for the validity of this digital certificate and have verified that it is issued to the correct organization or person.

And how does the certificate authority identify itself. By another digital certificate. And how do you know this digital certificate is trustworthy? By yet another certificate authority, vouching for this intermediate certificate authority.

This obviously cannot continue forever. This is why TLS relies on root certificates. These certificates are ultimately trusted, meaning you simply accept that they are valid.

In order for this certificate chain to work in practice, these root certificates are installed in every web browser as they are distributed by the web browser vendor.

Who do you trust?

The web browser's ultimate trust in root certificates is distributed among a large number of corporations like Verisign, Thawte, COMODO, Microsoft, Deutsche Telekom, Entrust, Geotrust, Equifax, GlobalSign, Go Daddy, GTE CyberTrust, Starfield Technologies, and USERTrust. These comprise the list that my Internet Explorer 8 contains.

Firefox 3 contains the following staggering list: TÜRKTRUST, ABA.ECOM, AC Camerfirma SA, AddTrust AB, America Online, AOL Time Warner, Autodidad de Certificacion Firmaprofesional, Baltimore, beTRUSTed, Certplus, COMODO, DigiCert, DigiNotar, Digital Signature Trust, Entrust, Equifax, GeoTrust, GlobalSign, Taiwan Goverment Root Certification Authority, GTE Corporation, IPS Internet Publishing Services, IPS Seguridad, NetLock Halozatbiztonsagi, Network Solutions, QuoVadis, RSA Data Security, SECOM Trust, SecureTrust, Sonera, Staat der Nederlanden, Starfield Technologies, StartCom, Swisscom, SwissSign, TC TrustCenter for Security in Data Networks, TDC, Thawte, Go Daddy, USERTRUST, Unizeto, ValiCert, VeriSign, VISA, Wells Fargo, and XRamp Security Services.

So: Who decides which companies are admitted into this inner circle of ultimately trusted organizations? What means do they take to ensure that they are as trustworthy as they claim. And why is there such a large difference between Microsoft's and Mozilla's list?

A Snake Oil Market: Issuing Digital Certificates

These certificate authorities have created an artificial market, selling their trust at a high price. Furthermore, since digital certificates always have an expiration date, after which the certificate is no longer valid, they have ensured return customers as well.

The organizations provide little added value, apart from the aforementioned trust. But are these certificate authorities really more trustworthy than the organizations forced to purchase digital certificates from them?

What Is Wrong With TLS

It boils down to trust. If you were to make a top ten list of the organizations you trust most -- what would these organizations be? And are any of the organizations mentioned above on that list?

Why can't you choose for yourself who to trust?

What is TLS supposed to protect?

TLS protects the data transmitted between the browser and the web server. Often this is your personal or confidential data, like user identification, financial information or other data which you would like to be kept secret, and that the organization you exchange data with often is mandated to protect.

What are the risks involved?

The most severe risk is that a certificate authority issues a certificate to the wrong people. These people could then pose as the organization the certificate is issued to, and steal your personal data without you being aware of it. The browser would claim the communication is secure with a trustworthy party, and it's impossible to detect that something wrong is going on.

A Better TLS Key Exchange

Remember, the primary purpose of the digital certificate is to exchange and protect the key used to encrypt the data in transit between the browser and the web site.

This key could be protected in other ways, two of which are suggested here:

1. The browser issues a digital certificate

The web browser can generate a self-signed certificate and present it to the web server when initiating a TLS session. The web server doesn't know whether this certificate is trustworthy, but that doesn't matter. It's only a matter of exchanging an encryption key in a secure manner, not trust. Most web sites require you to log on to identify yourself and establish this trusted relationship.

This certificate can be generated when the browser starts, and be destroyed when the browser exits.

2. The encryption key is based on shared secrets

The encryption key, or a scheme to generate an encryption key, can be shared between the browser and the web site. This can be based on the user's authentication data like user name and password. The browser can then start sending encrypted data, expecting the web site to know how to decrypt them.

A Better Trust Model

Since the data exchanged is yours -- shouldn't you decide whether you trust the organization you exchange data with?

This could be solved by removing the intermediate steps in the trust chain. Either you trust the party you are exchanging data with, or you do not. The decision is yours and yours only.

For example, when you establish a customer relationship with an organization, this organization could send you a self-signed digital certificate identifying itself. You would then choose whether you accept or reject this certificate.

Conclusion

TLS in itself is not broken, but the trust model employed is. Furthermore, the TLS protocol does not need to change, at least not significantly, to implement the improvements suggested. The key exchange part needs to be revised, and the way browsers handle digital certificates must change.

But it would create an overall more trustworthy solution, removing an unnecessary middle man.

Why submitting clear text passwords is bad

Jeff Atwood reminds me why even submitting passwords in the clear to a web site can be dangerous: You basically have to trust that they are storing the password in a secure fashion.

Which they more often than not don't.

Coding Horror: I Just Logged In As You: How It Happened:

"I guess I can tell you, so you don't fall into this trap again. There's a site I help out with that doesn't salt their passwords. They're MD5 encrypted, but if you've got a dictionary password, it's very easy to use a reverse-MD5 site to get the original. I was able to figure out you were a user on the site some time back, and realized I could do this, if only I knew your openid provider..."

There are basically two ways of solving this:

1. Use different passwords for different web sites. SuperGenPass takes the hassle out of this by generating a password based on a master password and the site's domain name.
2. Hash the password in the browser before submitting. My blog entry Password Authentication Without Revealing Your Password demonstrates a solution to this one.

I really wish client side hashing was more prominent than it is. I have seen it in action only two or three times, one of those implemented by myself.