openssl with Rust
Environment is Windows, Visual Studio Code, the Shining Light openssl build and the openssl crate. Does anyone have experience getting this to link? Environment variables? cargo.toml anything else?
Re: server key exchange signature behavior
Hi, see comments/questions inline On 23/06/20 14:03, Bruce Cloutier wrote: Hello, We administer a server (Windows) with a Bitnami stack for a Wordpress implementation and that uses Apache Httpd and OpenSSL. Separately I am developing the TLS ECC aspect of a controller device implementation and note a problematic behavior with the server_key_exchange for ECDHE_RSA. The developed device ECDHE_RSA suite works properly and as expected with all of the other servers thus far tested. There is likely a configuration issue with this Apache installation and I am fishing for a hint. you mention TLS ECC, suggesting Elliptic Curve Crypto, which might indicate EC-encoded certificates as well, yet talk about ECDHE_RSA which is Elliptic-curve Diffie-Hellman Exchange with RSA (for which you'd normally use RSA-encoded certificates. Now you can use both with httpd+openssl but you do need to specify the right certificate (or certificates) when configuring mod_ssl - you can even concatenate the RSA-signed certificate and the EC-signed certificate in a single hostcert.pem and mod_ssl will pick up both , simply using # Server Certificate: # Point SSLCertificateFile at a PEM encoded certificate. If # the certificate is encrypted, then you will be prompted for a # pass phrase. Note that a kill -HUP will prompt again. A new # certificate can be generated using the genkey(1) command. SSLCertificateFile /etc/httpd/certs/hostcert.pem # Server Private Key: # If the key is not combined with the certificate, use this # directive to point at the key file. Keep in mind that if # you've both a RSA and a DSA private key you can configure # both in parallel (to also allow the use of DSA ciphers, etc.) SSLCertificateKeyFile /etc/httpd/certs/hostkey.pem I'd recommend to take your test cert+key and see if you can run it using openssl s_server against openssl s_client (use 'openssl s_server -help' and 'openssl s_client -help' for the parameter list). If *that* works and apache+mod_ssl does not then you're looking at an mod_ssl configuration issue. HTH, JJK The issue is that the RSA signature as part of the server_key_exchange does not decrypt with the supplied certificate public RSA key. It does indicate an rsa_pkcs1_sha256 signature. With a fresh Bitnami install that still uses the default key and certificate files, the protocol provides a valid digital signature. When we change the server's certificate (and confirm this with the browser) the server_key_exchange signature no longer validates. It is as if the server continues to use the default key for the signature. I have not tried to confirm that specific point. My immediate question for someone close to the code is where does Apache/OpenSSL look for the key file for this signature at this point in the protocol? I am hoping that there is just some additional configuration location that needs to be given our new key file and/or certificate. Can anyone confirm? We noted this concern on a production server. We then installed the stack on a different machine to confirm the fresh install operation. In adding different key and certificate files we confirm that the signature then fails. If I ignore the bad signature the secure communications succeed. I have been searching the net for this issue for weeks. That has been fruitless. So I am turning to this list.
server key exchange signature behavior
Hello, We administer a server (Windows) with a Bitnami stack for a Wordpress implementation and that uses Apache Httpd and OpenSSL. Separately I am developing the TLS ECC aspect of a controller device implementation and note a problematic behavior with the server_key_exchange for ECDHE_RSA. The developed device ECDHE_RSA suite works properly and as expected with all of the other servers thus far tested. There is likely a configuration issue with this Apache installation and I am fishing for a hint. The issue is that the RSA signature as part of the server_key_exchange does not decrypt with the supplied certificate public RSA key. It does indicate an rsa_pkcs1_sha256 signature. With a fresh Bitnami install that still uses the default key and certificate files, the protocol provides a valid digital signature. When we change the server's certificate (and confirm this with the browser) the server_key_exchange signature no longer validates. It is as if the server continues to use the default key for the signature. I have not tried to confirm that specific point. My immediate question for someone close to the code is where does Apache/OpenSSL look for the key file for this signature at this point in the protocol? I am hoping that there is just some additional configuration location that needs to be given our new key file and/or certificate. Can anyone confirm? We noted this concern on a production server. We then installed the stack on a different machine to confirm the fresh install operation. In adding different key and certificate files we confirm that the signature then fails. If I ignore the bad signature the secure communications succeed. I have been searching the net for this issue for weeks. That has been fruitless. So I am turning to this list. Bruce -- Sent using Thunderbird on Ubuntu 16.04LTS signature.asc Description: OpenPGP digital signature
Re: repetitive ssl send
I have a state machine with the following states: create, connect, send,
receive.
When the state sequence is the following: create, connect, send, receive
everything is ok (with my code, sent in the previous email). However when
there is a receive code after connect there is a problem. There is no data
after this receive phase (maybe is not problem) but after that: send
executed successfully and the receive returns with no data.
create
connect
receive : no data, maybe ok
send: ok
receive : no data here !!
create: calls CreateSSL
connect: calls ConnectSSL
send: calls SendSSL
receive: calls ReceiveSSL
What may the problem?
Attila
On Mon, Jun 22, 2020 at 7:35 PM Viktor Dukhovni
wrote:
> On Mon, Jun 22, 2020 at 03:17:41PM +0200, Attila Csosz wrote:
>
> > char HEADERS[] = "GET /search?q=arduino HTTP/1.1\r\nHost:
> > www.google.com\r\nConnection:
> close\r\n\r\n";
> > char HOST_NAME_PORT[] = "www.google.com:443";
>
> Note the "Connection: close" in the HTTP request header!
>
> > void init_openssl()
> > {
> > SSL_load_error_strings();
> > SSL_library_init();
> > }
> >
> > void CreateSSL()
> > {
> > // Create SSL context
> > meth = SSLv23_client_method();
> > if (!meth) throw Exception("SSL: method");
> >
> > ctx = SSL_CTX_new(meth);
> > if (!ctx) throw Exception("SSL: SSL_CTX_new");
> > old_opts = SSL_CTX_set_options(ctx, SSL_OP_ALL);
>
> The SSL_CTX need only be created once, not once per connection.
> You've made no provision for verifying the server certificate.
> Typically you would load trusted CA certificate locations into
> the SSL_CTX.
>
> > web = BIO_new_ssl_connect(ctx);
> > if (!web) throw Exception("SSL: BIO_new_ssl_connect");
> > }
>
> This code belows in the ConnectSSL function.
>
> >
> > void ConnectSSL()
> > {
> > // Connect
> > res = BIO_set_conn_hostname(web, HOST_NAME_PORT);
> > if (!res) throw Exception("SSL: BIO_ctrl");
> >
> > res = BIO_get_ssl(web, );
> > if (!res) throw Exception("SSL: BIO_ctrl");
> >
> > res = SSL_set_cipher_list(ssl, PREFERRED_CIPHERS);
> > if (!res) throw Exception("SSL: SSL_set_cipher_list");
> >
> > res = BIO_do_connect(web);
> > if (res <= 0) throw Exception("SSL: BIO_do_connect");
> >
> > res = BIO_do_handshake(web);
> > if (res <= 0) throw Exception("SSL: BIO_do_handshake");
>
> This connection is unauthenticated. Perhaps that's OK, but often it is
> not.
>
> > }
> >
> > void SendSSL()
> > {
> > // Send
> > err = BIO_puts(web, HEADERS);
> > if (err <= 0) throw Exception("SSL: BIO_puts");
> > }
> >
> > void ReceiveSSL()
> > {
> > // Read
> > sResult = "";
> > for (;;) {
> > len = BIO_read(web, buf, sizeof(buf));
> > sResult += buf;
> > if (len <= 0)
> >break;
> > }
>
> The server closes the connection after returning its reply.
> You need to close the SSL BIO to avoid a memory leak.
>
> > -
> > It is ok for one request.
> >
> > My problem when I trying to send a new search request to google it works
> > only when I call
> > CreateSSL();
> > ConnectSSL();
> > again
>
> Naturally, you're not doing HTTP/1.1 connection keep-alive, and in any
> case would need to be prepared for the server to close the connection
> now and then. You need an actual HTTPS library, naive open-coding of an
> HTTP client over SSL is unlikely to be correct. Something like libcurl
> or similar is the way to go.
>
> > What may the problem?
>
> You're writing a naïve HTTPS client from scratch. A correct
> implementation would understand "Content-Length" and chunked
> trasfer encoding, handle server-initiated disconnects, be
> prepared to receive multi-record responses, ...
>
> --
> Viktor.
>
Re: Record Layer Buffers & Zeroization
On 23/06/2020 11:57, Martin Elshuber wrote: > Thx for the answer, > > than at least a can stop looking for this :). > > And yes I can understand the performance hit and I agree that this > should be optional and disabled by default. > > I am thinking of adding a OPENSSL_cleanse just ofter the memcpy in > ssl3_read_bytes. And probably replacing the OPENSSL_free by an > OPENSSL_clear_free in SSL3_BUFFER_release. The later gets rid of data > not yet deliverd to the application. > > I am thinking to make both dependent on a flags such as > SSL_OP_CLEANSE_PLAINTEXT. But I am not sure how to select a suitable > bit, since all unused bits are currently stated to be reserved for > openssl 1.2. We don't allow features in stable branches, so this could only be included in the forthcoming OpenSSL 3.0 (i.e the master branch). You can use those reserved values there because we are not aiming for ABI compatibility (only API). > > Another option is to add a compiler option; Though I do not like this > too much. > > Did I forget any locations where to more cleanses? Any other suggestions? > > If you are still interested, I am happy to prepare a PR and move the > discussion there. I guess this is "CLA: trivial" patch anyways. Please feel free to raise a PR - although this is unlikely to be CLA trivial (we have a very high bar for something to be considered trivial). Matt > > Martin > > Am 23.06.2020 um 12:19 schrieb Matt Caswell: >> >> On 22/06/2020 18:28, Martin Elshuber wrote: >>> I might be blind, but I just cannot find the location where this >>> plaintext data is >>> zeroized, neither by OPENSSL_cleanse() nor memset(). >>> >>> Am I blind, or is this just not done? Shouldn't there be a way to do >>> this just like >>> it is already done with keys? >> We don't currently do this. There would likely be some significant >> performance impacts for doing this with all plaintext. That said it >> might be a nice optional feature to add. >> >> Matt > >
Re: Record Layer Buffers & Zeroization
Thx for the answer, than at least a can stop looking for this :). And yes I can understand the performance hit and I agree that this should be optional and disabled by default. I am thinking of adding a OPENSSL_cleanse just ofter the memcpy in ssl3_read_bytes. And probably replacing the OPENSSL_free by an OPENSSL_clear_free in SSL3_BUFFER_release. The later gets rid of data not yet deliverd to the application. I am thinking to make both dependent on a flags such as SSL_OP_CLEANSE_PLAINTEXT. But I am not sure how to select a suitable bit, since all unused bits are currently stated to be reserved for openssl 1.2. Another option is to add a compiler option; Though I do not like this too much. Did I forget any locations where to more cleanses? Any other suggestions? If you are still interested, I am happy to prepare a PR and move the discussion there. I guess this is "CLA: trivial" patch anyways. Martin Am 23.06.2020 um 12:19 schrieb Matt Caswell: > > On 22/06/2020 18:28, Martin Elshuber wrote: >> I might be blind, but I just cannot find the location where this >> plaintext data is >> zeroized, neither by OPENSSL_cleanse() nor memset(). >> >> Am I blind, or is this just not done? Shouldn't there be a way to do >> this just like >> it is already done with keys? > We don't currently do this. There would likely be some significant > performance impacts for doing this with all plaintext. That said it > might be a nice optional feature to add. > > Matt
Re: Record Layer Buffers & Zeroization
On 22/06/2020 18:28, Martin Elshuber wrote: > I might be blind, but I just cannot find the location where this > plaintext data is > zeroized, neither by OPENSSL_cleanse() nor memset(). > > Am I blind, or is this just not done? Shouldn't there be a way to do > this just like > it is already done with keys? We don't currently do this. There would likely be some significant performance impacts for doing this with all plaintext. That said it might be a nice optional feature to add. Matt
