I am stuck to retrieve the Key_block generated after the SSL handshake. I implemented a simple Client.cpp/Server.cpp program that is working well for exchanging encrypted data.
I would like to retrieve the key_block because I want to re-use it and perform my own encryption in another communication, but without having another handshake again.
I tried :
ssl->s3->tmp.key_block
but it retrieves an empty string (?!) and of course
ssl->s3->tmp.key_block_length
retrieves 0 value.
I call these methods just after SSL_accept(ssl) succeeds.
Once I've been able to catch this key_block, I'll need to find the encryption function used by SSL_write(...)
Hope you hear me, because the openSSL doc seems encrypted to my eyes.. =)
XY problem. You don't need this. Just open another SSL connection to the same target and it should re-use the same SSL session and therefore the same session master secret. Maybe even the same session key, but what do you care, as long as it's secure? You seem to be just trying to avoid a second full SSL handshake, but you can do that by suitable configuration at the client.
Related
I am implementing a Web proxy (in C), with the end goal of implementing some simple caching and adblocking. Currently, the proxy supports normal HTTP sites, and also supports HTTPS sites by implementing tunneling with HTTP CONNECT. The proxy works great running from localhost and configured with my browser.
Despite all of this, I'll never be able to implement my desired features as long as the proxy can not decrypt HTTPS traffic. The essence of my question is: what general steps do I need to take to be able to decrypt this traffic and implement what I would like? I've been researching this, and there seems to be a good amount of information on existing proxies that are capable of this, such as Squid.
Currently, my server uses select() and keeps all client ids in an fd_set. When a CONNECT request is made, it makes a TCP connection to the specified host, and places the file descriptor of both the client and the host into the fd_set. It also places the tuple of fd's into a list, and the list is scanned whenever more data is ready from select() to see if data is coming from an existing tunnel. The data is then read and forwarded blindly. I am struggling to see how to intercept this data at all, due to the nature of the CONNECT verb requiring opening a simple TCP socket to the desired host, and then "staying out of it" while the client and host set up their own SSL sockets. I am simply asking for the right direction for how I can go about using the proxy as a MITM attacker in order to read and manipulate the data coming in.
As a brief aside, this project is solely for my own use, so no security or advanced functionality is needed. I just need it to work for one browser, and I am happy to get any warnings from the browser if certificate-spoofing is the best approach.
proxy can not decrypt HTTPS traffic
You are trying to mount a man-in-the-middle attack. SSL is designed to prevent that. But - there is a weak point - a list of trusted certificate authorities.
I am simply asking for the right direction for how I can go about using the proxy as a MITM attacker in order to read and manipulate the data coming in.
You can get inspiration from Fiddler. The Fiddler has its own CA certificate (certification authority) and once you add this CA certificate as trusted, then Fiddler generates server certificates for each connection you use on the fly.
It comes with serious security consideration, your browser will trust any site. I've even seen using the Fiddler core inside a malware, so be careful
Is it possible to always have a shared object with SSL session id reuse but optionally reuse the connection?
Scenario: we have one long poll loop which needs connection reuse and ssl ticket id. Additionally there are from time to time WS calls that send some statuses and they need also Ssl ticket but would like to contain the connection only to that call not to have it linger for max connection age.
Is this possible ? Can i maybe extract SSL session and put it into another curl object? Or any other way?
Or on those one off calls i can put maxage = 0 or keepalive = 0
BR,
Thank you!
As far as I can tell, the SSL session ID is already reused on a given easy handle. To reuse across easy handles, you have to call curl_share_setopt() to set prameter CURLSHOPT_SHARE to option CURL_LOCK_DATA_SSL_SESSION.
Relevant documentation:
CURL_LOCK_DATA_SSL_SESSION
SSL session IDs will be shared across the easy handles using this
shared object. This will reduce the time spent in the SSL handshake
when reconnecting to the same server. Note SSL session IDs are reused
within the same easy handle by default. Note this symbol was added in
7.10.3 but was not implemented until 7.23.0.
From:
curl_share_setopt()
As seen in the curl mailing list
Disclaimer: I haven't personally tried this, but it appears to be supported.
When i register a callback using SSL_CTX_set_cert_verify_callback, I get the callback. The ctx contains the cert but I cant seem to find the whole cert chain sent by the client. Does anyone know which field in the ctx would have it ? or how can i retrieve it so that I can do the full validation.
SSL_CTX_set_cert_verify_callback(ctx, ssl_app_verify_callback, NULL);
Thanks...
The verify callback for client certificates works the same way as the callback for the server certificates, i.e.
OpenSSL will build the chain based on what the client has send and what the server knows as local CA path.
For each part of the chain the verification callback will be called. This means that the callback will be called for local certificates which are part of the trust chain even if the client has not send them. And the callback will not called for certificates which are not part of the chain even if the client has send them.
If the client will send chain certificates depends on the client. But there is nothing in the standard which makes this impossible and openssl s_client -cert leaf.pem -CAfile chain.pem ... can be used to make the client send both leaf and chain certificates.
The chain of certs sent by the client is stored in the ctx->untrusted structure which is a stack of certs considered 'untrusted' because it is not part of the trust store. You don't really need to access this chain because openssl will automatically use it while performing the certificate chain validation process. In fact, I would be careful modifying this, since it could have unintended consequences. Refer to this thread on the openssl forum which cautions against changing the struct.
I want to login with a file that contains digital certificate of someone, first registers with certificate contents that is base64 format, and when registering it will encrypt the content of certificate and save into database and when login with this file, i want to login with that data matched by decrypted way, pls help how to do this? And also when i encrypt each time file content saved with different characters, is it possible to save 3323 characters in database? pls help.....
// controller
$main_file = $request->file;
//$con = $main_file->getClientOriginalName();
$con = file_get_contents($main_file->getRealPath());
$files = Crypt::encrypt($con);
dd($files);
$file = Input::file('file')->getClientOriginalName();
$contents = File::get($main_file);
dd($contents);
Now to authenticate with this saved encrypted data, what is the possible way to save the encrypted 3322 characters in database, i am really in a stuck. can anyone help me...the main task is to login with file contents..thanks...
Sounds like you're trying to implement some kind of shared private key authentication. It's not clear why you want to do that (more on that later), but it sounds like a bad idea right from the start because you are immediately confronted with a difficult problem: how do you get the private key from the client to the server in a secure way?
A better way to do it would be a private/public key system, similar to the sort of thing SSH does when you set up passwordless login. Basically (very basically - I'm not an expert) the idea is that the client generates a private/public key pair and then sends the public key to the server. On authentication, the private key is used to encrypt a message. This encrypted message is sent to the server, where the public key is used to decrypt it. If the correct message was received, then the client is authenticated.
Rather than having some sort of shared certificate, I'd recommend following this model. That way you don't have to share sensitive information (the client's private key) with the server.
Ultimately, you need to think about why you want to do this.
You think this will be more convenient for clients? Well, for SSH, it certainly is more convenient to log in this way, because SSH has a mechanism for automatically encrypting and passing messages in a secure way. For HTTP? Not so much. The user is going to need to generate a file then use an upload form just to log in. Passwords are much quicker and easier.
You think it will be more secure? The way you've described it (a shared private key) will probably be less secure because you somehow have to get the private key from the client to the server without it being compromised - remember, if the private key is compromised, anyone can impersonate the client. The way SSH does it is more secure because the private key never leaves the client.
Ultimately, I think you can probably get what you're looking for with a) strictly enforced password complexity rules and b) HTTPS.
If security on your site is so important that you cannot rely on HTTPS and complex passwords, then you should probably be looking at a more comprehensive solution that will encrypt all traffic between the client and the server, such as a VPN (virtual private network).
For educational purposes I'm implementing a simple remote shell program, and I'm trying to wrap my head around how to make it somewhat secure. The first idea I had was to just require a password. If the client sends the password, it runs, if not, it quits. Then, I applied a simple hash function to the password, but I don't think this really makes it any more secure. In either case, if the packets are intercepted, an attacker could just extract the password or the hashed password. What can I do to make this more secure Is there a way to use password/hashing that is safe from basic packet interception? I know that ssh uses public/private keys to encrypt and decrypt, but that is more advanced than I need.
How about a challenge/response with digests? Say the server knows the password is "blah".
The client connects, and authenticates:
Client: Let me in!
Server: I give you the challenge "12345", a number I generated just now!
Server remembers that they gave the client "12345".
Client wants to authenticate with "blah", so they add it to the end of the server's challenge, and then calculates the SHA-1 of the result "12345blah".
Client: My response is "6910972fb3148a63df7fda34bd6fccf3013d8d93"!
Server knows the password is "blah", and issued the challenge "12345" to this client—hence it calculates the SHA-1 of "12345blah", and produces "6910972fb3148a63df7fda34bd6fccf3013d8d93". This matches the client's response so …
Server: Access granted!
Important notes:
The server MUST be the one to choose the challenge. If the client gets to pick, then an attacker could just intercept one authentication attempt, and repeat the same challenge and response as that valid user.
The fact that the server picks a different challenge every time means an attacker can't replay authentication. This means the server needs to store the challenge against the client's connection or session somehow, since you'll need it when they respond.
You may want to use something stronger than SHA-1 (it's a little broken IIRC). You may also want to do something other than just appending the password to the challenge, as the security properties depend on the underlying digest function.
I demonstrate this with a password "blah", but the nice thing is now, you can replace "blah" with the hash of "blah". The server never needs to store more than the hash, and then the client just hashes their password first before combining with the challenge and calculating the digest.