There's a scene confused me: If I intercept the request, And I send the my CA which is official to client, it can through the verification from client? And This mitm would go on?
MITM means exact what you say. You have a intermediate component that plays as a client for the end server and as the end server for the original client.
Your MITM component establishes a connection to the end server in a regular ssl manner - hence it knows all the response properties of a server. It then encrypts the data with its own private key and sends the response further on to the original client with new fake certificate generated for the same subject as the original service address.
It signs generated certificate with your custom CA private key.
Since your custom CA root cert is trusted by the client, the client will accept the certificate from your MITM and won't report any issue.
Related
I would appreciate it if you could confirm the following for me:
Assuming I implement the following protocol using NodeJS over an insecure socket connection (I believe it is a common implementation and it is how SSL works), will my communication end up being safe by the end of it? It would be nice if you could confirm that this manual implementation is in fact an alternative to certificates.
There are other posted questions similar to this one, but I couldn't find one that confirms the signature part of the protocol which, according to my knowledge, beats the MITM attack.
Server sends his public key to the connected client
Client sends his public key to the server
Server sends a challenge to the client to ensure he has the private key to the public key that was exchanged (asking the client to prove himself)
Client sends a signed challenge to the server using his private key
Server verifies the signature using the client's public key
If the verification works, the client is who he claims he is (beats MITM attack)
If the verification fails, it means that the client lied about who he is by sending a public key he does not own
At this point, the server either fully trusts the client or not.
The server can now generate an AES key and send it in an encrypted manner to the client using the client's public key
Both ends have the AES key and all future communication is encrypted.
Thank you.
I've read a lot of related topics in the net, but I still don't have an answer to my question.
Is it possible to implement flow described below?
Proxy receive request.
If request is encrypted and proxy cert is trusted then intercept.
If request is not encrypted, then intercept.
If request is encrypted and proxy cert is NOT trusted then pass it through without interception.
This behaviour should be default for all traffic going through the proxy.
It'd be also really nice to be able to get all possible info for passing encrypted requests (src and dst ip addresses etc.). Basically the same info which I can get with fiddler.
Not really. The main problem is that mitmproxy can not know if proxy cert is trusted by the client or not.
In the SSL/TLS protocol client starts with the CLIENT_HELLO and in response the server (in this case motmproxy) sends back the SERVER_HELLO message containing the generated server certificate.
The client now checks if the received server certificate is trusted. If not the connection is terminated. As far as I know the SSL/TLS spec does not define how to do so. Sems clients end back an SSL_ALERT message, other simply drop the connection, and a third group continues the SSL/TLS handshake but have certain internal values set in a way that always let the handshake fail.
There is a mitmproxy script that tries to identify connections that were not successful and then if the client asks for the same domain a second time bypasses interception.
Of course this requires that the client resends requests which is not always the case.
https://github.com/sociam/x-ray/blob/master/mitmproxy/examples/tls_passthrough.py
I have a question concerning Sonos' client certificate. I didn't find any mention of it in the official documentation pages.
Do the speakers automatically send the client certificate on getMediaUri requests or does the server need to require it in the SSL negociation?
It would be neat if the speakers sent the client certificate all the time, because if the server needs to explicitly require the client certificate on the secure endpoint it means other APIs are impacted (createItem for example) whereas the only thing that really needs to be secured is the streaming url.
The server does not need to require sending the cert on each request, but if you DO require it, it is something that can be sent each time.
Scenario: Sensitive information is exchanged (1) from client to server AND (2) from server to client.
Problem: Data exchanged is not encrypted, so sniffing is easy (it's always theoretically possible, right?)
Solution: Encrypt all data transmitted in either direction (server-to-client and client-to-server).
Implementation:
(1) Client to server - Generate certificate, install private key on server and configure Tomcat to work on HTTPS (Many tutorials for this online).
(2) Server to client - Private key goes to (or generated by) clients, however it seems that some tutorials strongly emphasize that that every client should have their own certificate for the sake of authentication.
Question: If I am already authenticating my users through a database username/password (hashed with salt) combo, but I still need to encrypt server-to-client data transmissions to reduce chance of sniffing, can I just generate one private key for all clients? Are there other ways of achieving what I need with Tomcat/Spring?
It seems you're mixing something up:
Regular https includes encryption in both directions, and only a private key + certificate on the server side. Once a client requests resources through https, they get the answer encrypted. So you'll just need to enforce the https connection (e.g. by redirecting certain requests to https with no delivery of data through http)
If you want client certificates, these are purely used for client authentication, so sharing a common client key/certificate with all possible clients will defeat this purpose. Having client keys/certs does not add any more encryption to your data transfer.
Answering to your follow-up question in the comment:
For https, the server keeps its private key, the public key is what is shared with the client. On typical https, the client can be reasonably sure who the server is (authentication, done through the trustworthy signature on the server's public key. This is what you pay trustcenters for) However, the server has no clue who the client is (here client certificates would come into play, but purely for authentication, not for encryption)
Server and client negotiate a common session key. For this purpose there are many different implementations of the key-exchange protocol. This forum is probably not the right place to describe session negotiation and the ssl handshake again, but you can be sure that you only need a server side key for the purpose you describe above: Take any website as an example: If you go to google mail, their https encryption works through them having a private key and a certified (signed) public key: You have no client side certification, but provide your username and password through the encrypted connection to them. Otherwise you'd have to install a client side key/certificate for a lot of services - and that would be too much of a burden for the average internet user.
Hope that helps.
How does the browser figure out the destination in an HTTPS connection? All the headers are encrypted..
Update:No this is not a homework.. my name is student because I'll always be learning in this HUGE awesome field
When a browser views an url like https://www.gmail.com/ first thing your browser does is resolves www.gmail.com to 72.14.213.19.
Next your browser opens up a TCP connection to 72.14.213.19 on port 443.
The browser & server before ANY headers are transmitted negotiate a public key encryption scheme (RSA) based on the SSL Certificate that is digitally signed.
In this process the browser checks the certificate authenticity before communicating.
Once this trust between client & server has been established, the client now can encrypt the headers in a way the server can decrypt. It proceeds to make the HTTP request inside the SSL Tunnel.
The server decrypts the message, serves the request and encrypts it in a way that that particular client can decrypt.
The browser then decrypts the response, reads the headers and makes decisions about how to proceed from there.
This has been an overview of an HTTPS connection event. :D
The string containing https: that you typed in the browser is what the browser uses. That is not encrypted,
Probably more than you'd ever want or need to know about the The First Few Milliseconds of an HTTPS Connection I'd go into more detail explaining stuff if your username wasn't student, and this wasn't likely homework.