Category Archives: Network

Internet. Networking.

Estimated-Content-Length

Greg Dean posted an interesting idea on the ietf-http-wg mailing list, suggesting that a new response header would be added to HTTP (Estimated-Content-Length:) to allow servers to indicate a rough estimation of the content length in situation where it doesn't actually now the exact size before it starts sending data.

In the current world, HTTP servers can only report the exact size to the client or no size at all and then the client will have to just deal with the response becoming any size at all. It then has no way to know even roughly how large the data is or how long the transfer is going to take.

The discussions following Greg's post seem mostly positive thus far from several people.

In the middle there is a man

The other day an interesting bug report was posted against the Firefox browser, and it caused some interesting discussions and blog posts on the subject of Man-In-The-Middle attacks and how current browsers etc make it (too?) easy to accept self-signed certificates and thus users are easily mislead. (Peter Burkholder wrote a great piece on SSL MITMing already back in 2002 which goes into detail on how this can be done.).

The entire issue essentially boils down to this:

To be able to really know that you're communicating with the true remote site (and not an impostor), you must have some kind of verification system.

In SSL land we have this system with CA certs for verifying certs and it works pretty good in most cases (I think). However, so many sites on the internet use HTTPS today without having the certificate signed by a party that is known to the browser already - most of them are so called self-signed which means there's nobody else that guarantees that they are who they claim to be, just themselves.

All current modern browsers want to give the users easy access to HTTP sites, to HTTPS sites with valid properly-signed certs but also allow users to connect to and browse on HTTPS sites with self-signed certs. And here comes the problem: how to tell users that HTTPS with self-signed certs is very insecure but still let them proceed? How do we tell them that the user may proceed but if this is a known popular site you really should expect a true and valid certificate as otherwise it is quite possibly a MITM you're seeing?

People are so used to just accept exceptions and click away nagging pop-ups so the warnings and alerts that are explicit and implied by the prompts you have to go through to accept the self-signed certificate. They don't seem to have much effect. As can be seen in this bug report, accepting an impostor's certificate for a large known site is far too easy.

In the SSH land however, we don't have the ca cert system and top-down trust hierarchy that SSL/TLS imposes. But does this matter? I'd say no, as most if not all users still don't reflect much over the fact when a server's host key is reported different than what you used before. Or when you connect to a host the first time you accept the host key without trying to verify it using a different channel. Thus you're subject to pretty much the same MITM risk. The difference is perhaps that less "mere end users" are using SSH this way.

Let me just put emphasis on this: SSL and SSH are secure. The insecureness here is not due to how the protocols work, but rather they are flaws that appear when we mix in real world users and UIs and so.

I don't have any sensible solutions to these problems myself. I'm crap at designing things for mere humans and UIs etc and I make no claims of understanding end users.

It seems there's a nice tool called ettercap that's supposedly a fine thing to use when you want to run your own MITM attacks on your LAN! And on the other side: an interesting take at improving the "accept this certificate" UI is offered by the Firefox's Perspectives plugin which basically also checks with N other sources' view to help you decide whether to trust a certificate.

I want to round off my rant with a little quote:

"I have little, and decreasing, desire to continue to invest in strong security for a product that discards that security for the masses" [*] / Nelson B Bolyard - prominent NSS hacker

FTP vs HTTP, really!

Since I'm doing my share of both FTP and HTTP hacking in the curl project, I quite often see and sometimes get the questions about what the actual differences are between FTP and HTTP, which is the "best" and isn't it so that ... is the faster one?

FTP vs HTTP is my attempt at a write-up covering most differences to users of the protocols without going into too technical details. If you find flaws or have additional info you think should be included, please let me know!

The document includes comparisons between the protocols in these areas:

  • Age
  • Upload
  • ASCII/binary
  • Headers
  • Pipelining
  • FTP Command/Response
  • Two Connections
  • Active and Passive
  • Firewalls
  • Encrypted Control Connections
  • Authentications
  • Download
  • Ranges/resume
  • Persistent Connections
  • Chunked Encoding
  • Compression
  • FXP
  • IPv6
  • Name based virtual hosting
  • Proxy Support
  • Transfer Speed

With your help it could become a good resource to point curious minds to in the future...

HTTP implementations

I previously mentioned on the libcurl mailing list, that Mark Nottingham in the IETF HTTP Working Group has initiated the work on putting together an overview of all (interesting) existing HTTP implementations

Of course curl is included in the bunch, or rather libcurl, but I would also urge you all to step forward and provide further details on other implementations you worked on or know of!

Will 2008 become 1984?

Next week in Sweden (June 18th), as reported in several places lately including slashdot, the Swedish parliament is supposed to vote for the pretty far-going law allowing FRA (a swedish defence organization previously involved in radio-surveillance etc) to wire-tap phone calls and computer traffic that cross the Swedish borders. The majority in the parliament is for the law, while it seems most of the ordinary people are against it. The hope is now that a few people will vote against their parties, that they will have the guts to stand up and "do the right thing" instead of following the party line.

I won't go into how silly, stupid and bad such a law is but I'll instead just show this great video to all swedes:

(video snipped from here)

stopa FRAlagen nu

This banner says (roughly translated by me) "On June 18th the government will take away your personal integrety. All internet traffic, all phone calls, all email and SMS traffic will be wire-tapped starting January 1st 2009. Big brother sees you! ... and violates the Swedish Constitution."

public suffixes list

I noticed the new site publicsuffix.org that has been setup by the mozilla organization in an attempt to list public suffixes for all TLDs in the world, to basically know how to prevent sites from setting cookies that would span over just about all sites under that "public suffix".

While I can see what drives this effort and since we have the same underlying problem in curl as well, I have sympathy for the effort. Still, I dread "having to" import and support this entire list in curl only to be able to better work like the browsers in the cookie department. Also, it feels like a cat and mouse race where the list may never be complete anyway. It is doomed to lack entries, or in the worst case list "public suffixes" that aren't any such public suffixes anymore and thus it'll prevent sites using that suffix to properly use cookies...

There's no word on the site if IE or Opera etc are going to join this effort.

Update: there are several people expressing doubts about the virtues of this idea. Like Patrik Fältström on DNSOP.

The IPv6 failure being joined by DNSSEC?

In case you haven't read it before, Randy Bush's 55 page PDF slide show named "IPv6 Transition & Operational Reality" is a harsh (but quite accurate) description of how the IPv6 protocol was made, where some of its major problems lie and why the transition is going so slow etc.

I tried to find some official and recent figures or statements from some of the more IPv6-positive people and companies, but I failed to find much updates from after the year 2000 or so...

Speaking of network things that aren't so successfully deployed: DNSSEC. Apparently iis.se (runs the Swedish TLD) tested 10 broadband routers (article and PDF in Swedish only) how well they support this (I believe mainly because .se tries to be a pioneer in DNSSEC), and 7 of the tested ones failed... Personally I've never liked the fact that DNSSEC isn't really crafted to do it securely all the way.