Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

TO BE CLEAR: I'm NOT looking to write my own protocol, or my own client-side implementation. I'm looking for an EXISTING protocol, part of the HTTP standards, that is generally ALREADY supported by common browsers. (Such a thing may not exist.)

I have an HTTP application that needs some protection from man-in-the-middle threats. (The server needs to be able to prove the authenticity of its responses to the client.) Encryption is irrelevant and unnecessary. Also, the hardware budget is pretty small, given the expected hit rate.

Normally, I'd just get a cheap certificate and enable SSL on the web server, but a load-generator killed both Apache and Nginx (and I don't expect any other web servers to be do any better). For non-HTTP service, the load is fine. I also tried configuring the HTTPS server to negotiate a null encryption cipher. That helped a little, but the SSL handshake is still too heavy.

A simple SHA-1 signature (generated by the server) over the response document, verified by the client, would suit me just fine. I wrote a simple Python FastCGI script and HTTP client to test just the bare SHA-1 operation--it adds some load, but not much, not even close to what SSL with null encryption adds. In practice, though, my clients won't be Python scripts, they'll be web browsers.

(AGAIN, TO BE CLEAR: I'm not proposing my own crypto protocol, the Python script was just a test of how much load the SHA-1 hash generates, by itself, versus the rest of the SSL negotiation. I cannot use a custom client-side implementation, because I have no way of installing it for all of the client browsers.)

So: Are there any EXISTING lightweight (compared to SSL) server authentication protocols for HTTP?

share|improve this question
Belongs on – Billy ONeal Jul 13 '10 at 0:00
@Billy ONeal: If custom client-side and server components were a possibility, I'd agree with you. But since I have to interact with ordinary browsers coming from the general public, installing client-side code isn't really an option, unless I could do it in JavaScript/Flash/etc. – Ryan B. Lynch Jul 13 '10 at 13:24
Also, it's not what you asked for, but you could buy a cheapish SSL accelerator, either in the form of an add-on card, or a processor/mobo that has one built in (Via Padlock). – Bill Weiss Jul 22 '10 at 15:00
up vote 6 down vote accepted

What you're looking for doesn't really exist. The lightweight mechanism built in to the browsers and servers is SSL.

share|improve this answer
Thanks, @Bill Weiss. If that's the answer, then that's the answer. – Ryan B. Lynch Jul 13 '10 at 19:43
Seems like nobody has a better idea, so I'm going to accept. Thanks. – Ryan B. Lynch Jul 16 '10 at 13:38
I'm the cheerful bearer of bad news? :) – Bill Weiss Jul 22 '10 at 14:59
If the answer is "no", I appreciate a direct, straightforward "no". Suggestions and alternatives are helpful, too, but it's frustrating when well-meaning StackOverflow users jump to conclusions (based on unfounded assumptions about my situation) and start telling me that my "real problem" is something else. 95% of the time, they're wrong, and their tones are irritating or downright insulting. – Ryan B. Lynch Jul 24 '10 at 19:47
This is definitely the correct answer. TLSv1+ can 'barely' protect HTTP from MITM when implemented properly. The slightest mis-configuration, or using anything less (such as older versions of TLS/SSL) and you're open to one of many and varied attacks on HTTP. It's as lightweight as the use-case asks for; and that's why it's only on the cutting-edge of being 'secure'. – Rushyo Oct 17 '14 at 9:57

If you're injecting a SHA1 in your content, and I'm MITMing you, what keeps me from just fixing the SHA1 as well?

share|improve this answer
Because the server would generate the SHA-1 sig using its private key, and the client would verify against the server's public key. (I could have made that a little clearer, sorry.) There's a pretty good diagram, here: – Ryan B. Lynch Jul 13 '10 at 13:26
I know how SHA-1 works, my point was that your spec was missing it. – Bill Weiss Jul 13 '10 at 18:02
What spec? Re-read the question, I hope I've made it clear enough, now: I'm not trying to code a new protocol. You're fixating on something that's beside the point. – Ryan B. Lynch Jul 13 '10 at 19:33

Some workarounds include:

  • HTTP Digest for usernames / passwords
  • DNSSEC for server address validation
  • make ajax handshake mechanism and HMAC page validation. If you insert page imitating public / private key mechanism - third party can easily tamper with data, else MITM can also easily fix data hash. Remember that cryptography is rarely done right, so stand on others shoulders and use proven mechanism.

    I suggest that you use ssl, with tuned nginx (look at ssl sessions and cyphers). Otherwise your MITM will be just parody and wasted work and cpu cycles.

share|improve this answer
How would HTTP Digest usernames/passwords allow the server to prove it's identity to the client? To my understanding, HTTP auth is strictly about the client proving its identity to the server. – Ryan B. Lynch Jul 13 '10 at 13:33

Depending on how much control you have over the client, you could replace the trivially breakable SHA1 with HMACSHA1. The problem with HMACs is that they require a secret key to be known on both sides of the transmission beforehand. Anyone with access to your client would probably be able to extract the secret-key by disassembling it.

HMACSHA1 Diagram

We have used this before for cases where we had two separate web servers, one which provided the website, and one which processed orders, which were located in geographically distinct datacenters. This made sure nobody would be able to send requests directly to the fulfillment server and bill people.

share|improve this answer
I'm not trying to write my own protocol, here. I'm wondering whether there is an existing protocol. It looks like a bunch of people misunderstood that, I'll rewrite the question to make it as clear as possible. – Ryan B. Lynch Jul 13 '10 at 13:31
@Ryan: If that's the case all that's going to work is SSL. – Billy ONeal Jul 15 '10 at 4:37

The problem with using an obscure or bespoke protocol for signing is that it's not already built into the browser(s). This means you need to provide the validation logic to the remote browser. If you don't have protection from a MITM attack when you deliver that code/logic, then what stops the MITM from just replacing the validation code with something that returns "VALID" no matter what it sees - and/or, what stops the MITM from extracting the shared secret used for the HMAC from the client-side validation code, and using that in the MITM attack?

If you just can't do realtime SSL crypto, could you reorganize your process so that you're using HTTP to deliver pre-computed responses which were GPG-signed, or otherwise signed offline as part of a batch process? If you need to include data from the user in computing/determining the response, could you add requests to a batch-processed queue, with GPG-signed results delivered later via the user polling an HTML response page, and/or via E-mail?

Do you need this to be available 24x7x365, or is this used sporadically? (e.g., registration -type events where you have a lot of load on one day or week, then nothing for months) If it's the latter, could you use a cloud-based server you just rent for a day or a week then spin down until you need it again?

share|improve this answer
I appreciate the response, but I think you misunderstood my intention. I don't want to write my own protocol--I want to know whether there's an EXISTING protocol, already generally supported by browsers, that can provide lightweight authentication. – Ryan B. Lynch Jul 13 '10 at 13:30
Ah. I think Bill Wiess is on the right track when he says that SSL/TLS is that protocol. – gbroiles Jul 14 '10 at 1:29

Instead of trying to solve the wrong problem, grab an encryption acceleration card or put Nginx in front of your web server in an SSL accelerator/reverse proxy configuration and be done with it.

share|improve this answer
+1, Solve the right problem! Also, Soekris makes a crypto-board that will do ~70 connections/s that's pretty cheap: – Chris S Jul 13 '10 at 18:51
@gravyface: While I appreciate the vigor, I don't think you're appreciating the real problem. More hardware (or new hardware) isn't an option, here, because of the constraints of the project. But thank you for the suggestion, anyway. – Ryan B. Lynch Jul 13 '10 at 19:36
@Chris S: Those PCI cards sure are cheap, but 70 hits/sec doesn't even get close to the traffic requirements, here. There are more powerful SSL accelerators, but see the original question regarding the budgetary constraints, here. – Ryan B. Lynch Jul 13 '10 at 19:38
@Ryan: how much do you value your time? How much does your employer value your time? You could spend countless hours trying to reinvent the wheel here when buying a decent dual core machine with a couple of GBs of RAM (~750 bucks) could solve this problem. – gravyface Jul 13 '10 at 19:45
The problem you're facing is that HTTP was never meant to be secure at all. When there was a need for security SSL was invented to solve the problem. Your problem is more specific yet, and there is no widely accepted solution. The SHA signature is a decent idea, but you'll have to have JavaScript or something on the client verifying it. There's no way around it. – Chris S Jul 13 '10 at 19:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.