0

Is there a way to sign http request in Volley?

As far as I understand SSL connection.

  • client opens connection
  • server responds with cert that contains public key
  • client stores server's public key
  • client creates request and signs it with server's public key
  • server verifies request using own private key

If server sends the response, client verifies response with server's public key?

How does ssl pinning fits in this process?

Jakub Gruber
  • 745
  • 1
  • 11
  • 27

2 Answers2

1

I think you got the gist of it as far I as I know. SSL pinning is just verification of the CA certificate provided by the server response.

I think this url got it right. Maybe it might help you

SSL Pinning with Volley network library on Android

Rohit Pothuraju
  • 83
  • 6
  • But if server finally sends me response, how do I verify that? He should sign it with public key and client should verify it using private key. I do not see where client's private key came from. – Jakub Gruber Jun 05 '17 at 11:45
  • In a more general sense, the trusted CAs must exist beforehand, in a key store. When the response arrives the client checks whether the received CA is authentic by checking this keystore with the help of a trustmanager. You do not need to know where the clients key is from it should satisfy certain criteria to prove authenticity – Rohit Pothuraju Jun 05 '17 at 11:55
  • And just last note. Do I, as a client, sign request with (some) private key or with server's public key? – Jakub Gruber Jun 05 '17 at 11:58
  • 1
    Yes, kinda, it should send a symmetric response key (using the server key) that the server can decrypt and use to authenticate the client. Here are some links that may help....https://www.digicert.com/ssl/ http://blog.ostorlab.co/2016/05/ssl-pinning-in-android-networking.html – Rohit Pothuraju Jun 05 '17 at 12:07
1

No, it does not work this way. There is no signing of the HTTP request. In short:

  • client establishes a TLS connection to the server which involves
    • the server sending a certificate to the client
    • the client validating this certificate, i.e. that it is trusted, matches the servers name and that the server owns the private key belonging to the certificate. Certificate pinning will be checked in this step too, i.e. if the certificate (or its public key) matches the expected value.
    • followed by the key exchange which results in keys for encryption and message protection
  • from then on all data exchanged is encrypted and protected against modification

TLS itself has no idea of HTTP, i.e. does not know what a HTTP request and response is. It only sees a data stream which it protects. HTTP request and response are part of this stream and are thus protected but there is no specific signing of the HTTP request or response.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • @JakubGruber: the result of the key exchange is a pre-master secret which is transformed to a master secret which is then used to derive the secrets for encryption and HMAC. The exact details are not that important but if you are interested see [How does SSL/TLS work?](https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work) or have a look at [the TLS standard](https://www.ietf.org/rfc/rfc5246.txt). – Steffen Ullrich Jun 05 '17 at 13:31
  • So.. The stream is protected, because I verified server's key and I trust it. (because I have its public key pinned and it matches). Later, I send requests and I do not need to sign them. But can I if I'd like to? – Jakub Gruber Jun 05 '17 at 13:32
  • @JakubGruber: there is no mechanism defined for HTTP to sign HTTP requests and it is also not possible if you use HTTP on top of TLS (i.e. HTTPS). But there should be no need to do this with HTTPS since because of TLS the request is like all other data protected against manipulation. – Steffen Ullrich Jun 05 '17 at 13:32