Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

using https for websites ensures that the communication is encrypted and comes from and goes to the right server. BUT https is really slow compared to http, it also breaks the http cache protocol.

Sometimes it's enough to ensure the user is on the right domain and the content was not modified during the connection. So what i don't understand is why isn't there a way to make digital sign the web content an send the signiture (or hash) via http header, so the browser can validate the content. The certificate could be made available at a known place or by an additional header field. The resulting Protocol would be compatible with almost every HTTP stuff like caching, proxies, and browsers( if the browser does not understand the header it can ignore it. a new browser could show if the site is valid or not).

So where here is the question: Was this topic discussed before? Or is there a RFC or something that can sign web pages already?

share|improve this question
Are you talking about sHTTP? – SamK Jul 21 '11 at 13:26
no i don't think so, i removed 'shttp' from my question, thank you. – user67689 Jul 23 '11 at 8:07

PGP (or GPG) can sign webpages, and the same utility can verify the signatures. There's no support from browsers however, so users would have to manually check the pages.

Honestly it sounds like an interesting idea; the main problem I can think of is trusted distribution of the keys, and signing authorities. The same CAs used for SSL Certs could issue Document Signing certificates (or something similar), but with the lack of any standard or large demand you're in a "chicken and egg" problem.

share|improve this answer
it's possible to use the normal SSL Certs for the document signing, is't it? I coul'd try to provide a protocol description, webserver and browser plugins but maybe some one has done this work before. – user67689 Jul 23 '11 at 7:55
A "SSL Cert" is an X509 Certificate with Key Usage set to "Server Authentication". A certificate could be issued for "Document Signing" which would allow exactly what you're talking about. But the current SSL Certs do not include that Key Usage. If they were used for Document Signing (technically possible, though most programs would object) the client would fail document authentication because the key used for signing isn't allowed to sign. Similarly any cert could technically be used for make your own CA, but again, clients would recognize that something's wrong. – Chris S Jul 23 '11 at 15:07

You can do what you're asking with SSL: Simply configure your server to use a NULL cypher set (e.g. NULL-SHA or NULL-MD5) - Your data will NOT be encrypted however, and it' still subject to the same caveats as any other https connection (caching proxies probably won't work, etc.)

The result is an authenticated connection, but without the overhead of encryption/decryption. Browser support varies however: Some may not be pleased about NULL cyphers, and may make their displeasure known to the user via a warning message.

share|improve this answer
About 90% of the overhead of SSL is negotiating the secure link. Any I don't know of any browsers that support NULL encryption in the default configuration. – Chris S Jul 21 '11 at 13:47
@Chris - True Re: negotiation, but keepalives help with that. Re: NULL encryption, Firefox used to support it out of the box, but I assume they've disabled that by now. – voretaq7 Jul 21 '11 at 13:57

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.