What is URL Signer ?

URL Signer is a lighweight security tool written in Java by Alan Moran that permits clients ("senders") to securely issue URL requests to servers ("recipients")

URL Signer uses Digital Signature Algorithm (DSA) principles so that the recipient can be assured that the URL was issued by a trusted sender. Accordingly URL Signer does not require the use of complex security middleware (e.g., a user database or PKI) nor does it make use of shared-secret schemes (which are generally considered not safely scalable.) Instead URL signer relies on the sender being in possession of a DSA private key and the recipient being in possession of the corresponding public key both of which need to be protected.

URL Signer is appropriate for applications that use a HTTP based interface (e.g., use of a URL to issue a command to a web application) and require a simple but secure means of validating requests. URL Signer can be safely used over HTTP or can be used togerther with a HTTPS channel if additional TLS/SSL services are required. URL Signer is superfluous in environments that already employ two-way TLS/SSL together with PKI.

For example imagine that you have a JSP page which accepts commands via HTTP using a "cmd" parameter with perhaps some optional arguments then a user might issue a command to the application by sending a HTTP request (e.g., via wget) of the form:

http://urlsigner.sourceforge.net?cmd=shutdown

Of course if the command is publicly known or can be viewed over the network then anyone can issue this command to the server. This presents a secure risk that is not abated by attaching user credentials or similar to the password since any such URL can be merely resent by an interceptor in what is known as a replay attack. What is needed is a way of ensuring that there is something in the URL that the recipient can use to determine that it was sent by a trusted sender. In effect URL Signer provides this by adding cryptographic parameters to the URL that the recipient can use to verify that the sender was in possession of the private key at the time the URL was issued. Moreover the parameters are in such a form that any signed URL can only be issued once. Thus when the above URL is signed it takes the form

http://urlsigner.sourceforge.net?cmd=shutdown&urlsPRNG=6ukqiiTMNU4kTK04K%2FtL0A%3D%3D&urlsTs=RnJpIEZlYiAyNiwgMjAxMCAxNjo1NzoyNCBHTVQrMDE6MDA%3D&urlsSig=MCwCFBRrpILD99t0uz4BHPn%2Fv3evdt3SAhQFz4mlT5I%2F8%2FuuSKYxwPeIwvfDNA%3D%3D

How does URL Signer work ?

URL Signer is based on well established crytographic signing practices using Digital Signature Algorithm (DSA) public/private keys. In what follows the sender is in possession of a private key and the recipient possesses the corresponding public key. No certificates are involved (a certificate is an electronic means of binding key materials to an identity e.g., a person or an entity.) and no shared secrets are used (a shared secret is a long term "secret key" that is provided to each pariticipant but this is generally considered neither a scalable nor, for related reasons, a secure approach)

In essence URL signer leaves the original URL untouched but adds the following elements:

The process works as follows:

URL signing
  1. The sender generates a nonce and a timestamp (using the current date/time) Using its private key it performs a digital signature operation wherein the original URL, the nonce and timestamp are first hashed using the Secure Hash Algorithm (SHA) and then encrypted (using the private key.) The nonce, timestamp and signaure (all suitably URL encoded) are then appended to the URL and sent to the recipient.
  2. The receipient application extracts the nonce, timestamp and original URL and validates as follows:
    • If the timestamp is older than 5 minutes based on the recipient's clock then the URL is rejected;
    • Else if the URL has already been received within the last 5 minutes based on the recipient's clock then the recipient regards it as a replay attack. and rejects it;
    • Otherwise the recipient extracts the nonce and timestamp from the URL and recomputes their hash. By comparing this with the decrypted signature (using its public key) it can ascertain whether the sender was in possession of the private key and therefore if the request is legitimate.

All the above operations (e.g., nonce generation, timestamping, URL encoding and cryptographic operations) are performed by URL Signer which exposes a very simple command line and API interface to users.

To ensure URL signing works the following requirements must be fulfilled:

  1. Any sender to be trusted must be in possession of the private key and any recipient that is to trust a sender must be in possession of the corresponding public key.
  2. Both the sender and the recipient should have (reasonably) synchronized clocks. By "reasonable" I mean that clock drift should not exceed 5 minutes e.g., use of Network Time Protocol (NTP) is recommended. Internally ULR Signer uses an arbitrary but consistent time format so that signing operations behave well over multiple timezones.
  3. The recipient should maintain a cache of signed URLs requests (this cache is provided in the URL Signer API) received within the last 5 minutes in order to detect request signatures that have been sent repeatedly within the permitted time interval. In practice this means that the recipient is usually a server (e.g., a web container) and is not terminated immediately after a verification operation (i.e., it lives long enough to "remember" replay attempts!)

What does URL Signer protect against ?

URL Signer provides the following security services and features:

  1. Simplicity URL Signer avoids the need to employ user credentials and/or Public Key Infrastructure (PKI) by relying solely on the use of key materials. Accordingly URL Signer is simple to deploy and satisfies most needs of applications that handle HTTP requests.
  2. Integrity The recipient can be assured that the URL was issued by a legitimate sender and that nothing has been tampered with, i.e., if the underlying URL, nonce or timestamp are altered then the signature no longer matches and verification will fail.
  3. Replay Attacks If a sender (or anyone else who has intercepted a request) re-issues the same request then the recipient will observe that the request already exists in its cache and will reject it. The lifetime of a valid request is limited to 5 minuts (a convention borrowed from the Kerberos protocol) in order to ensure that the cache will not grow too large over the operational lifetime of the recipient.
  4. Man-In-The-Middle Attackes If a request is intercepted over an insecure channel then its contents can be read but cannot be altered or re-issued as described above. Moreover owing to the limited lifetime of the request is automatically expires after 5 minutes thus becoming useless.

What does URL Signer not protect against ?

URL Signer does not provide the following services:

  1. Privacy URL signer does not attempt to "hide" the URL so an interceptor of the request might still be capable of gleaming useful information. If this is a concern then an encrypted channel (e.g., HTTPS) should be used in addition to URL Signer.
  2. Certification Possession of the private key alone is sufficient to issue a secure request. There is no attempt by URL Signer to bind this key to an identity (e.g., a person or entity) and therefore there is no facility to revoke the validity of a key should it fall into the wrong hands. In such cases a new public/private key pair should be re-issued and redistributed to participating senders and recipients.
  3. Non-Repudiation URL Signer provides no means of repudiation in the event of a claim on the validity of a signature.

Could TLS/SSL be used instead ?

TLS/SSL provides channel security for HTTP traffic by ensuring integrity and privacy of the channel. This means that attackers are thwarted from reading and/or tampering with the content of a HTTPS request or response. In addition TLS/SSL can also provide authentication for one or both participants. This is commonly used to certify servers in order to establish trust with clients though the protocol also enables client certification in what is known as "Advanced" or "Two-Way" TLS/SSL.

If you already employ Two-Way TLS/SSL then there is no need for URL Signing since the SSL handshake phase will fail if a client (i.e., sender) is not trusted. You must, however, issue client certificates to trusted senders and the use of Two-Way TLS/SSL therefore typically requires a Public Key Infrastructure (PKI) in order to operate. I recommend that you use one if you have one but URL Signer can alleviate this overhead by offering a simpler solution that is suitable in most situations that operate outside of a PKI.

If you are using standard TLS/SSL (i.e., a certified server but not certified clients) then sending unsigned requests is unsafe. You may, however, use URL Signer over a HTTPS channel if you require the additional services of TLS/SSL.