Tag Info

New answers tagged

1

No, new versions of TLS have not removed cipher suites defined in older versions.1 Which version of TLS you use and which cipher suite you use are two linked but separate matters (you can't always use a new cipher suite in an old TLS version). OpenSSL is just listing which version the cipher suites were first added in. The PRF is mostly used for key ...


3

You can only use the ECDHE-RSA ciphers from that list if all you have is an RSA certificate. Same thing for ECDSA certificates, which only can be used with the ECHDE-ECDSA ciphers on that list. ECDH-* is fixed in the sense that your certificate contains the fixed public parameters for and key, which can be used for the key exchange. This certificate is then ...


1

At the moment, the only drawback is compatibility. But if that's not an issue for you then you're golden.


3

CVE-2014-5139 - crash with SRP ciphersuite in Server Hello message - SRP had been removed from LibreSSL in May 2014 so no fix was necessary. CVE-2014-3512 - SRP buffer overrun - again not vulnerable because SRP is no longer part of LibreSSL CVE-2014-3505 - Double Free when processing DTLS packets - this had been fixed independently by LibreSSL back in May ...


2

Philosophical differences. LibreSSL is designed under the philosophy that an SSL library should be an SSL library, and nothing more. This means it doesn't try to implement half of libc, or provide other OS-level facilities, and it should not compensate for flaws in the OS -- the OS should be fixed instead. A pool of high-quality entropy is one of those ...


0

The answer is a little murky, somewhere between the two. Linux has historically exposed the kernel's random number generator as /dev/random and /dev/urandom while BSD exposes it with the getentropy syscall. It turns out there are some advantages to the BSD approach, and because of LibreSSL pressure, Linux will be implementing a similar syscall. more info ...


1

The answer to your specific scenario is "it depends". Specifically, it depends on the finer details of how the application's memory allocator works, the threading mechanism it uses, and the application's inner structure. There are some scenarios (eg. old-fashioned fork+exec threading with a new thread to handle each request, or a memory allocator that ...


0

Heartbleed is a memory scraping bug. Its not just keys that can be found, but ANY data that the affected machine handled. In the case of this proxy, then, the heartbleed vulnurabilty could see the memory in another process, that happened to be your customer's HTTP request to your server. Due to the nature of this flaw, ANY sensitive information that has ...


5

It's actually not a SHA1 hash in the CSR. It's a signature of the message. For simplicity, I'll assume we are talking about RSA certificates, where the public key is (N, e) (the modulus and public exponent which is typically 65537) and the private key is (N, d) (the modulus and the private exponent which can be easily calculated via Euclid's extended ...


2

You can add, for example the -sha256 flag to the OpenSSL command line when generating the CSR. I don't believe any CA will change how they sign your CSR based on this, and it certainly won't affect the certificate chain. They're not resigning the cert chain for each key, the only signature operation they do is on your CSR itself. Any intermediate/root CAs ...


0

I'm not sure if this is exactly what you're looking for but s_server will send the full list of ciphers as well as common ciphers shared between the endpoints when you try to access the server: openssl s_server -accept 443 -www -cert /etc/ssl/certs/server.crt -key /etc/ssl/private/server.key This is the data sent to the client (Firefox, in this case): ...


2

The man page says it: Note: there are no ciphersuites specific to TLS v1.1. TLS 1.1 uses the same cipher suites as TLS 1.0, therefore OpenSSL does not make a distinction between the two. When it supports a cipher suite for TLS 1.1, it also supports it for TLS 1.0, and vice versa. TLS 1.2 has its own set of cipher suites because these include the ...


1

The certificate is available as long the SSL connection is open by calling SSL_get_peer_certificate, see https://www.openssl.org/docs/ssl/SSL_get_peer_certificate.html. It is no longer available after SSL close.


1

@david is correct that an attacker must be privileged: this is a MITM attack. There's another important detail: both users (server and client) must be using a vulnerable version of OpenSSL. For the web, while many servers use OpenSSL, none of the most popular clients do. None of Chrome, IE, Safari, Firefox, or Opera on the desktop use OpenSSL. See Which ...



Top 50 recent answers are included