Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Shttp

•Download as DOC, PDF•
•

S-HTTP is a secure protocol designed to work with HTTP that provides encryption and authentication. It allows for secure transactions between clients and servers through symmetric and asymmetric cryptography without requiring public key certificates. S-HTTP preserves the existing HTTP model while adding security features like encrypting form data and digital signatures. It supports a variety of cryptographic standards and algorithms to be negotiated between clients and servers.

1 of 2
S-HTTP: Secure Hypertext Transfer Protocol Secure HTTP (S-HTTP) is a secure message-oriented communications protocol designed for use in conjunction with HTTP. S-HTTP is designed to coexist with HTTP's messaging model and to be easily integrated with HTTP applications. Secure HTTP provides a variety of security mechanisms to HTTP clients and servers, providing the security service options appropriate to the wide range of potential end uses possible for the World-Wide Web (WWW). S-HTTP provides symmetric capabilities to both client and server (in that equal treatment is given to both requests and replies, as well as for the preferences of both parties) while preserving the transaction model and implementation characteristics of HTTP. Several cryptographic message format standards may be incorporated into S- HTTP clients and servers. HTTPS (S-HTTP) supports interoperation among a variety of implementations, and is compatible with HTTP. S-HTTP aware clients can communicate with S-HTTP oblivious servers and vice-versa, although such transactions obviously would not use S-HTTP security features. S-HTTP does not require client-side public key certificates (or public keys), as it supports symmetric key-only operation modes. This is significant because it means that spontaneous private transactions can occur without requiring individual users to have an established public key. While S-HTTP is able to take advantage of ubiquitous certification infrastructures, its deployment does not require it. S-HTTP supports end-to-end secure transactions. Clients may be "primed" to initiate a secure transaction (typically using information supplied in message headers); this may be used to support encryption of fill-out forms, for example. With S-HTTP, no sensitive data need ever be sent over the network in the clear. SHTTP provides full flexibility of cryptographic algorithms, modes and parameters. Option negotiation is used to allow clients and servers to agree on transaction modes cryptographic algorithms (RSA vs. DSA for signing, DES vs. RC2 for encrypting, etc.); and certificate selection. S-HTTP attempts to avoid presuming a particular trust model, although its designers admit to a conscious effort to facilitate multiply-rooted hierarchical trust, and anticipate that principals may have many public key certificates. HTTPS differs from Digest-Authentication in that it provides support for public key cryptography and consequently digital signature capability, as well as providing confidentiality. Another popular way of making secured web communication is HTTPS, which is the HTTP runs on top of TLS or SSL for secured transactions.
Protocol Structure - S-HTTP: Secure Hypertext Transfer Protocol Syntactically, Secure HTTP messages are the same as HTTP, consisting of a request or status line followed by headers and a body. However, the range of headers is different and the bodies are typically cryptographically enhanced. S-HTTP messages, just as the HTTP messages, consist of requests from client to server and responses from server to client. The request message has the following format: Request Line General header Request header Entity header Message Body In order to differentiate S-HTTP messages from HTTP messages and allow for special processing, the request line should use the special Secure" method and use the protocol designator "Secure-HTTP/1.4". Consequently, Secure-HTTP and HTTP processing can be intermixed on the same TCP port, e.g. port 80. In order to prevent leakage of potentially sensitive information Request-URI should be "*". S-HTTP responses should use the protocol designator "Secure-HTTP/1.4". The response message has the following format: Status Line General header Response header Entity header Message Body Note that the status in the Secure HTTP response line does not indicate anything about the success or failure of the unwrapped HTTP request. Servers should always use 200 OK provided that the Secure HTTP processing is successful. This prevents analysis of success or failure for any request, which the correct recipient can determine from the encapsulated data. All case variations should be accepted.

More Related Content

Shttp

  • 1. S-HTTP: Secure Hypertext Transfer Protocol Secure HTTP (S-HTTP) is a secure message-oriented communications protocol designed for use in conjunction with HTTP. S-HTTP is designed to coexist with HTTP's messaging model and to be easily integrated with HTTP applications. Secure HTTP provides a variety of security mechanisms to HTTP clients and servers, providing the security service options appropriate to the wide range of potential end uses possible for the World-Wide Web (WWW). S-HTTP provides symmetric capabilities to both client and server (in that equal treatment is given to both requests and replies, as well as for the preferences of both parties) while preserving the transaction model and implementation characteristics of HTTP. Several cryptographic message format standards may be incorporated into S- HTTP clients and servers. HTTPS (S-HTTP) supports interoperation among a variety of implementations, and is compatible with HTTP. S-HTTP aware clients can communicate with S-HTTP oblivious servers and vice-versa, although such transactions obviously would not use S-HTTP security features. S-HTTP does not require client-side public key certificates (or public keys), as it supports symmetric key-only operation modes. This is significant because it means that spontaneous private transactions can occur without requiring individual users to have an established public key. While S-HTTP is able to take advantage of ubiquitous certification infrastructures, its deployment does not require it. S-HTTP supports end-to-end secure transactions. Clients may be "primed" to initiate a secure transaction (typically using information supplied in message headers); this may be used to support encryption of fill-out forms, for example. With S-HTTP, no sensitive data need ever be sent over the network in the clear. SHTTP provides full flexibility of cryptographic algorithms, modes and parameters. Option negotiation is used to allow clients and servers to agree on transaction modes cryptographic algorithms (RSA vs. DSA for signing, DES vs. RC2 for encrypting, etc.); and certificate selection. S-HTTP attempts to avoid presuming a particular trust model, although its designers admit to a conscious effort to facilitate multiply-rooted hierarchical trust, and anticipate that principals may have many public key certificates. HTTPS differs from Digest-Authentication in that it provides support for public key cryptography and consequently digital signature capability, as well as providing confidentiality. Another popular way of making secured web communication is HTTPS, which is the HTTP runs on top of TLS or SSL for secured transactions.
  • 2. Protocol Structure - S-HTTP: Secure Hypertext Transfer Protocol Syntactically, Secure HTTP messages are the same as HTTP, consisting of a request or status line followed by headers and a body. However, the range of headers is different and the bodies are typically cryptographically enhanced. S-HTTP messages, just as the HTTP messages, consist of requests from client to server and responses from server to client. The request message has the following format: Request Line General header Request header Entity header Message Body In order to differentiate S-HTTP messages from HTTP messages and allow for special processing, the request line should use the special Secure" method and use the protocol designator "Secure-HTTP/1.4". Consequently, Secure-HTTP and HTTP processing can be intermixed on the same TCP port, e.g. port 80. In order to prevent leakage of potentially sensitive information Request-URI should be "*". S-HTTP responses should use the protocol designator "Secure-HTTP/1.4". The response message has the following format: Status Line General header Response header Entity header Message Body Note that the status in the Secure HTTP response line does not indicate anything about the success or failure of the unwrapped HTTP request. Servers should always use 200 OK provided that the Secure HTTP processing is successful. This prevents analysis of success or failure for any request, which the correct recipient can determine from the encapsulated data. All case variations should be accepted.