is rational to use a digital signature when I communicate data over TLS?
I currently for a financial application use tls for communication and I want to use digital signature for integirity of request message.
Yes, as TLS encrypts sensitive data but doesn't guaarantee the authenticity or integrity of an app, website or message sender. A digital signature ensures that the message has not been altered and was sent by the expected sender.
There are various methods and technologies available for adding digital signatures to your messages, such as PGP (Pretty Good Privacy) and S/MIME (Secure/Multipurpose Internet Mail Extensions).
Related
Is there any way that I can create a proof of a file downloaded using https? With proof I mean a cryptographic record of some sort that links the contents of a file to a site at a certain time. If I understand TLS correctly, the server certificate is only used as a basis to establish a session key that is known to both parties, so each request is not signed but just encrypted for transfer. Any ideas if this can be done and if so how?
In HTTPS the certificate is only used for authentication and with the obsolete RSA key exchange also for key exchange. Application data are only protected against modification by some man in the middle but they are not signed by the sender. While a HTTP server could be explicitly implemented to sign and timestamp the content, one can not enforce such operation against an arbitrary existing server.
For more see
Where in a TLS connection can I get the signature of the content sent by the server?
Why does HTTPS not support non-repudiation?
How to prove some server sent some file over HTTPS
Proving authenticity of data accessed over TLS by an untrusted third party
I want the ability to prove to a third party (not myself) that I received some given content from a given https server, or in other words, have a signature of that content that can be verified against the public key of the SSL certificate of a website.
According to this, it seems that a signature of the digest of the data is being sent and I am hoping that this is happening every time a page is loaded. If that is right, how/where can I see/extract that signature? (e.g. using curl, whatever command line, tool...)
If my last assumption is inaccurate, is there a way that I can produce the proof described above? And if so, how?
Thanks,
TLS uses data integrity control mechanism, but as the name suggests (TLS = Transport Layer Security), TLS is about protecting the data channel, not about "signing the data". TLS guarantees (or attempts to) that what has been sent via the protected channel remains unchanged in transit and it has not been altered by the third party. So you don't need to manually check any signatures besides the validation procedure performed by the TLS client on your behalf. If you trust your TLS client, then you trust the connection. You can perform additional checks of the certificate sent by the server, but you can't check the "signature of the digest of the data".
It's possible to craft a server which will calculate the signature of the data and put the signature to the response headers, but out of the box I didn't see any server doing this (or any client verifying such signatures).
I developed a secure SMS-exchange application that uses RSA (1024-bit) for session key exchange and Twofish (128bit) for SMS encryption. I used Bouncy Castle API. At this point, I need the application to be able to verify (other) users’ public key. I want this done by verification of users’ X. 509 digital certificate as in regular PKI. How do I go about generating an X.509 digital certificate that can be used on mobile phones (on the j2me application)?
Why a service certificate is required when non-windows client credential specified ?
(i found some specifications on the book said that, a service certificate can be used to negotiate a symmetric key for messaging encryption and signing when negotiation is enabled, but if negotiation is disabled, the client must reference the certificate in the store or including the BASE64 encoded public key, it comes out another question as below)
when the negotiation is disabled, definitely the service certificate will be used for encrypting message, because the client knows the public key, but which one will be used for message signing ?
when the transport security is enabled, and the service certificate is also specified, it said that the certificate will be used for negotiate a SSL session key for message signing and encryption, it applied to all the bindings ,such as HTTP, TCP, etc.
when we are using the windows client credentials, which one will be used for message encryption and signing?
thanks.
IF you choose to authentucate the client you can choose between windows credentials, username, certificate or SAML token. If windows auth is not available you need some other mechanism.
As for the other questions please be more specific. In general client will generate a temporary key (session key) which will be used to encrypt the message. Server certificate will encrypt the session key.
I am currently in the process of integrating a WCF client into a java web service. The server requires the client to authenticate via certificate using SSL and the message to be signed.
I have successfully sent the message to the server through SSL, Signed, etc. However, the server response message is also signed but with a different certificate than the one used to authenticate the server.
The WCF client doesn't like this behavior. It failed with the message: "The incoming message was signed with a token which was different from what used to encrypt the body. This was not expected." The problem is described here in detail.
Looking around on Google I found it is possible to decouple the clients transport certificate from the singing certificate by implementing ClientCredentials and other security related classes, and adding a new extension. You can read all the details about it here. However I'm having some trouble figuring out where exactly do i have to extend to provide this same behavior for the server's certificate on client mode.
Any help on the subject or reference would be appreciated.
Thanks in advance.
Have a look here
This shows you how to create an custom ServiceCredentialsSecurityTokenManager that allows you to specify the various message signing and encryption certificates for requests and responses to and from the server.
I emphasise message because the problem as you describe it appears to me to be message security validation. The transport security is seaperate from the mechanism used to validate the message security, i.e. the message signature and message decryption.
Ignore the transport security as this is lower down in the WCF pipeline and appears to be working working correctly from your description. A seaperate concern is the message security. It appears that you need to be able to use a certificate for decrypting the response and a certificate for verifying the signature. The above article shows a example for enabling this type of certificate managment, it does detail how you could create behaviours and extensions to apply this to your client that is a seaperate concern. This depends on how you want to configure your proxies i.e. through code or through configuration.
The example article you linked too is not a complete implementation for what you require, it only provides for a certifiate for signing and a certificate for the transport client credentials.
You could create a hybrid ServiceCredentialsSecurityTokenManager that provides the transport certificate and the signing and decryption, this should be clear enough from looking at the SecurityTokenRequirement documentation