S-HTTP EXPLAINED by Brett Griffiths
I thought it would be best to try to explain as much of this in my own words as I'm not to "familiar" with a lot of the technical terms used in what I read on the Net. So putting this in Layman,s terms (as much as possible) I will try to set this out expalining everything as if to someone new to the web.
So WHAT IS S-HTTP ?
I will start from the beginning. S-HTTP stands for "secure Hypertext Transfer Protocol" it was designed by E Rescorla and A Schiffman of Enterprize Intergration Technologies "EIT" to be an extention to the HTTP protocol to support sending data securley over the World Wide Web. It was designed to coexist with HTTP's messaging model and to be easily intergrated with HTTP applications or simply put "It keeps your moolah safe on its way from your wallet to a computer transaction on the internet".
Now not all browsers and servers support S-HTTP, another technology for transmitting secure communications over the web is "SSL" or Secure Sockets Layer with is more prevalent. The fact that S-HTTP and SSL have very different designs and goals it is possible and reccomended to use the two protocals together. Where SSL is designed to establish a secure connection between two computers, S-HTTP is desgned to send individual messages securly.
HOW DOES IT WORK
A Secure HTTP message is a request or status line, followed by other headers (which must be RFC-822 compliant), and some content. The content can be raw data, a secure HTTP message, or an HTTP message. The request is defined as :-
Secure * Secure-HTTP/1.1 to which the response must be:
Secure-HTTP/1.1 200 OK
These lines are defined to stop an attacker from seeing the success or failure of a given request. Secure HTTP takes a general paranoid attitude to all information, leaking as little as possible.
Headers
There are a few headers that should go in the Secure HTTP header. These are other headers which go into an HTTP header, which is located within the S-HTTP message. Those headers are defined in S-HTTP, but are used as headers in the HTTP document. ie, they cannot be used without being protected by an S-HTTP encapsulation.
Negotiation
To offer flexibility in the cryptographic enhancements used, clients and server negotiate about what enhancements each is willing to use, unwilling to use, or will be required to use. Negotiations blocks have four parts property, value, direction (always in respect to the negotiator), and strength (for preference). If agents are unable to discover a common set of algorithms, appropriate actions should be taken. Continuing to request a refused option is considered ineffectual and inappropriate.
An example negotiation line would be :
SHTTP-KEY_Exchange-Algorithims: recv-required+RSA,Kerb-5.
To mean messages to this machine must use Kereros 5 or RSA encryption to exchange keys.
Message format Options.
The format of the body of a message is indicated by the Content-Privact-Domain SHTTP header line. There are several acceptable Content-Privacy-Domains, which are PEM, PGP, and PKCS-7. Under PKCS-7, the most interesting option is a self signed signature certificate in a message body. This is permitted, and no assertions are made to its reliability. This allows implementers a great deal of flexibility.
Error Conditions and Retry Behavior.
Not all error in Secure HTTP result in connections being closed. Some will require a new attempt, with different option. The 3XX set of redirection codes provides the building blocks on which to proform redirection. Clients must interpret server messages to decide on the appropriateness or a retry.
Threats
Threats to S-HTTP are similar to those against SSL. However, the more general nature of S-HTTP make it difficult to assess exactly what is possible.In the case of a hacker, or looker, the attack on a CA may be more difficult due to the existence of Multiple CA's. A key could theoretically be verified by several CA's making an attack un feasible.
Protections offered
The default operational mode of S-HTTP is substantially more resistant to attach than that of SSL. It resists clear text cryptanalysis, Man in the Middle, and replay attacks. It is more robust than SSL, because option renegotiation and retries are permitted.
In conclusion you can readily see the importance of SHTTP, particularly to companies and business who are moving towards the cheapest for of transactions, like those that rely in E commerce like E bay and various web booking engines for airlines and financial institutions who use e banking and B pay.
It is also recommended to use SHTTP in conjunction with something like SSL to provide a more secure transfer of information.
So I hope with the above description of SHTTP you get the general idea of what is it and how it is used.
Brett
I thought it would be best to try to explain as much of this in my own words as I'm not to "familiar" with a lot of the technical terms used in what I read on the Net. So putting this in Layman,s terms (as much as possible) I will try to set this out expalining everything as if to someone new to the web.
So WHAT IS S-HTTP ?
I will start from the beginning. S-HTTP stands for "secure Hypertext Transfer Protocol" it was designed by E Rescorla and A Schiffman of Enterprize Intergration Technologies "EIT" to be an extention to the HTTP protocol to support sending data securley over the World Wide Web. It was designed to coexist with HTTP's messaging model and to be easily intergrated with HTTP applications or simply put "It keeps your moolah safe on its way from your wallet to a computer transaction on the internet".
Now not all browsers and servers support S-HTTP, another technology for transmitting secure communications over the web is "SSL" or Secure Sockets Layer with is more prevalent. The fact that S-HTTP and SSL have very different designs and goals it is possible and reccomended to use the two protocals together. Where SSL is designed to establish a secure connection between two computers, S-HTTP is desgned to send individual messages securly.
HOW DOES IT WORK
A Secure HTTP message is a request or status line, followed by other headers (which must be RFC-822 compliant), and some content. The content can be raw data, a secure HTTP message, or an HTTP message. The request is defined as :-
Secure * Secure-HTTP/1.1 to which the response must be:
Secure-HTTP/1.1 200 OK
These lines are defined to stop an attacker from seeing the success or failure of a given request. Secure HTTP takes a general paranoid attitude to all information, leaking as little as possible.
Headers
There are a few headers that should go in the Secure HTTP header. These are other headers which go into an HTTP header, which is located within the S-HTTP message. Those headers are defined in S-HTTP, but are used as headers in the HTTP document. ie, they cannot be used without being protected by an S-HTTP encapsulation.
Negotiation
To offer flexibility in the cryptographic enhancements used, clients and server negotiate about what enhancements each is willing to use, unwilling to use, or will be required to use. Negotiations blocks have four parts property, value, direction (always in respect to the negotiator), and strength (for preference). If agents are unable to discover a common set of algorithms, appropriate actions should be taken. Continuing to request a refused option is considered ineffectual and inappropriate.
An example negotiation line would be :
SHTTP-KEY_Exchange-Algorithims: recv-required+RSA,Kerb-5.
To mean messages to this machine must use Kereros 5 or RSA encryption to exchange keys.
Message format Options.
The format of the body of a message is indicated by the Content-Privact-Domain SHTTP header line. There are several acceptable Content-Privacy-Domains, which are PEM, PGP, and PKCS-7. Under PKCS-7, the most interesting option is a self signed signature certificate in a message body. This is permitted, and no assertions are made to its reliability. This allows implementers a great deal of flexibility.
Error Conditions and Retry Behavior.
Not all error in Secure HTTP result in connections being closed. Some will require a new attempt, with different option. The 3XX set of redirection codes provides the building blocks on which to proform redirection. Clients must interpret server messages to decide on the appropriateness or a retry.
Threats
Threats to S-HTTP are similar to those against SSL. However, the more general nature of S-HTTP make it difficult to assess exactly what is possible.In the case of a hacker, or looker, the attack on a CA may be more difficult due to the existence of Multiple CA's. A key could theoretically be verified by several CA's making an attack un feasible.
Protections offered
The default operational mode of S-HTTP is substantially more resistant to attach than that of SSL. It resists clear text cryptanalysis, Man in the Middle, and replay attacks. It is more robust than SSL, because option renegotiation and retries are permitted.
In conclusion you can readily see the importance of SHTTP, particularly to companies and business who are moving towards the cheapest for of transactions, like those that rely in E commerce like E bay and various web booking engines for airlines and financial institutions who use e banking and B pay.
It is also recommended to use SHTTP in conjunction with something like SSL to provide a more secure transfer of information.
So I hope with the above description of SHTTP you get the general idea of what is it and how it is used.
Brett
posted by Bretto | 4:59 AM
|
3 comments
