WebScarab Methods

I always lose the link to WebScarab methods. I thought I'd post the info here for myself, and anyone else who happens to need this info too.

If you are new to webscarab, then check out the webscarab tutorials listed in the sidebar to the right. Link for all webscarab posts

The Message class provides the following methods, which are common to both the Request and Response classes:

Request & Response have the following methods:

• String[] getHeaderNames()
• String getHeader(String name)
• void setHeader(String name, String value)
• void addHeader(String name, String value)
• void deleteHeader(String name)
• NamedValue[] getHeaders()
• void setheaders(NamedValue[] headers)
• byte[] getContent()
• void setContent(byte[] content)

The Request class adds the following methods:

• String getMethod()
• void setMethod(String method)
• HttpUrl getURL()
• void setURL(HttpUrl url)
• void setURL(String url) throws MalformedURLException
• String getVersion()
• void setVersion(String version)

The Response class adds the following methods:

• String getVersion();
• void setVersion(String version);
• String getStatus();
• void setStatus(String status);
• String getMessage();
• void setMessage(String message);
• String getStatusLine();

-Michael Coates

Crypto - Good Today, Broken Tomorrow

Let's talk a bit about encryption algorithms and recommended key sizes. What we are going to get at is the following question.

What if an attacker captures a large amount of encrypted data and attempts to crack the encryption 20 years from now?

NIST has provided guidance on selecting an appropriate crypto algorithm and key size to ensure that the encrypted data is adequately protected against brute force attacks. This calculation is based, in part, on expected technology growth and the ability for the key to be broken.

Remember, encryption is not impossible to break. Eventually someone will find the key. However, if you're using recommended algorithms and key sizes, the amount of time to brute force a key will exceed many lifetimes. The reason NIST issues guidance on recommended algorithm and key sizes is because as technology and computing power increases, the amount of time to brute force a particular crypto algorithm / key size decreases. Therefore, the key size must be sufficiently large to prevent a brute force with the available technology.

So this is all well and good. Check out the doc for more information on this subject.

SP800-57 Part 1 of 3 (Pages 63-66)

Here is my concern. The information we exchange today over SSL is protected by one of several different algorithms deemed "strong". That is strong for today, but not necessarily strong in 20 years from now. What if an attacker records a large amount of data today, and then attempts to crack that data in 20 years when technology is sufficiently more capable? For most data, I'm not too concerned. My passwords will have changed (if I'm even still using that site or passwords at all), bank information may have changed too. But what about data that doesn't change. Social security numbers, health records, company secrets, government secrets?

Now we are starting to see the problem. While I don't believe an attacker will really wait twenty years to try and get my SSN, I do see nations caching government data in hopes of obtaining secrets when they can crack the encryption in the future.

So the encryption you are using today may be strong, but are you comfortable with that data being exposed in twenty years from now?

A few screen shots for those interested....

Here are the OpenSSL ciphers categorized by strength.



And here is a sample connection to Google using a Low strength cipher. Modern browsers won't connect using these weak algorithms, but the point is that there still is a potential for weak crypto to be used. (Btw, Google is not the exception. Plenty of major banks also support weak crypto algorithms)




Final note: This little blurb only addressed one part of the whole encryption process. There are many other ways to mess up encryption (implement it wrong, compromise the key, other unrelated breaches which expose data). However, I still thought the above discussion was interesting and worth sharing.

-Michael Coates