Atanas Roussev – Senior Java Developer, UI Engineer, Web Developer Resume – Vancouver

Great news. HTTP4e was released few weeks ago. Today I found some time to post it.

New features:

Stay tuned for more news and examples.

I was playing with Ruby and tried HTTP4e on MyRadRails and it worked as a charm.

This is what I call write once run anywhere. Great job Eclipse!

Recently I had to explain how would I design a REST Authentication. My humble thoughts:

Using Basic or Digest is naive.

1. Basic token is a plain Base64 text. To make it worst, you need to send the username and password each time as part of the HTTP packet so any MitM attacker will be able to translate it.

2. The security aspect could be resolved by using Basic over SSL. Yet SSL has it’s performance drawbacks. And in your requirements SSL may not be an option.

3. Using the Digest as being secure, resolves 1 and 2, yet it has disadvantages as:
- The nonce is optional. Skipping the nonce MD5(username:nonce:password) could end up with Digest algorithm of MD5(username:password) which is not secure for simple passwords. Any computer today would be able to reverse engineer a simple password MD5 hash using available dictionaries.
- The Digest is optional. A MitM could tamper the packet and browser could fall back to Basic.

4. Digest and Basic when invoked within a browser environment has the annoying feature of opening a native popup with username/password.

5. Basic/Digest don’t expire. As long as you stole a Basic/Digest security token you can continue with the replay attack.

6. No prevention for tampering. Digest algorithm includes hashing the URI:Method:andBody yet, those algorithms are once again recommendations only and optional.

My prefer approach would be a

Custom Authentication Token a la Amazon

Amazon REST Authentication did a great job of providing a secure REST Authentication. Let’s dissect their token:

Example AWS Call:

GET /photos/puppy.jpg HTTP/1.1
Host: johnsmith.s3.amazonaws.com
Date: Mon, 26 Mar 2007 19:37:58 +0000
Authorization: AWS 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

where Authorization algorithm header is:

Authorization = "AWS" + " " + AWSAccessKeyId + ":" + Signature;

and signature:

Signature = Base64( HMAC-SHA1( UTF-8-Encoding-Of( YourSecretAccessKeyID, StringToSign ) ) );

and more:

StringToSign = HTTP-Verb + "\n" +
	Content-MD5 + "\n" +
	Content-Type + "\n" +
	Date + "\n" +
	CanonicalizedAmzHeaders +
	CanonicalizedResource;

CanonicalizedResource = [ "/" + Bucket ] +
	<HTTP-Request-URI, from the protocol name up to the query string> +
	[ sub-resource, if present. For example "?acl", "?location", "?logging", or "?torrent"];

CanonicalizedAmzHeaders = <described below>

Explaining:

• CanonicalizedAmzHeaders: Some special AWS business headers. Skipping..
• CanonicalizedResource: a string concatenating elements from HTTP packet being sent – URI, parameters, Method etc. Reason? Preventing HTTP packet tampering. Assuming an attacker stole the Authentication token, then stolen token could be used only within the current REST call as vital elements of the packet are being injected as part of AWS token.
• StringToSign and Content-MD5 etc.. – more tampering prevention and obfuscation.
• Signature: One way hash encryption of the whole amalgam above.

More  thoughts:

• The token will contain a time stamp so it will expiry on inactivity.
• The token could optionally contain business sensitive data too. userID or any businessID’s.

Lastly, depending on requirements, you may want to consider using OAuth too.

Have a crafty and secure fun!

Great news. HTTP4e adds BASIC and DIGEST Authentication support. Bellow is the Configuration Dialog on Ubuntu:

Another exciting news for HTTP4e. Fonts on Linux and Mac OS X have been finally fixed.

HTTP4e on Mac OS X Leopard:

HTTP4e on Ubuntu:

A good news for the Bulgarian community. HTTP4e supports unicode which means all those young kids can start start phishing on … drum rolls … unicode

Joke aside, have a look on the screenshots. Chinese and Cyrillic characters right on your favorite RESTful client. Cutie, eh?

Many people are complaining about HTTP4e don’t supporting Authentication. Yet, a bit of knowledge about Basic Authentication would help them realize that performing authenticated request  is nothing more than passing an additional “authentication” header.

Opening Wikipedia at http://en.wikipedia.org/wiki/Basic_access_authentication
the following sequence of packet negotiation is being passed across the wire:

Request One:

GET /private/index.html HTTP/1.0
Host: localhost

HTTP/1.0 401 Authorization Required
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:18:15 GMT
WWW-Authenticate: Basic realm="Secure Area"
Content-Type: text/html
Content-Length: 311

blah blah ...

Request Two:

GET /private/index.html HTTP/1.0
Host: localhost
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

HTTP/1.0 200 OK
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:19:07 GMT
Content-Type: text/html
Content-Length: 10476

What does this tell us? Request one is trying to retrieve a resource on server localhost. Receiving a response back with 401 Authorization Required, the client makes second attempt (Request Two) passing this time some magic header and the server seems to like it by giving back 200 OK.  The magic header is “Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==”. The formula of the encoded string is nothing else, but Basic64 encoded text, so any online Base64 tool will decode the text to its human readable “username:password” value.

Back to the original post. How does this relate to HTTP4e? Well the tool doesn’t have the GUI utility to plug this header to the request sending. Yet, this doesn’t mean it doesn’t support Base Authentication. All you need to do is pass that magic header into your requests. So if you construct an HTTP call against server www.abc.com protected by Base authentication with username:password, pass this additional header to to that call.

Authorization: Basic <the Base64 encoded string "username:password">

Thanks for reading this far.

Many of you probably sill think that the META headers are the solution for No-Caching.

<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="-1" />
<meta http-equiv="Cache-Control" content="no-cache" />

I came across this excellent tutorial by Mark Nottingham http://www.mnot.net/cache_docs/. It explains why ”Pragma: no-cache” doesn’t work and why you should use the Cache Control HTTP Headers instead.

Last-Modified
If-Modified-Since
ETag
If-None-Match
Cache-Control: max-age=3600, must-revalidate

The HTTP4e hidden features list is published. The tool has so many hidden features, such as auto complete, panel expand, proxy configuration, etc. Yet folks are totally unaware of them. My bad. It’s interesting how publishing a single list could take a year!

Read more