Tag Info

New answers tagged

0

des-ede3-cbc OpenSSL will tell you that encryption is des-ede3-cbc if you use asn1parse. Command: $ openssl asn1parse -in privkey.pem -i -dlimit 16 Output: 0:d=0 hl=4 l=1294 cons: SEQUENCE 4:d=1 hl=2 l= 64 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT :PBES2 17:d=2 hl=2 l= 51 cons: SEQUENCE 19:d=3 hl=2 l= ...


2

Your private key is encrypted with Triple DES. While DES is easily broken, Triple DES is safe for now, especially in this context. AES was made to replace Triple DES not so much because Triple DES was broken, but because it was way too slow. In the context of private key encryption, a non issue.


3

Why is there des-ede3-cbs in my rsa private key? Because your private key is encrypted with that. As far as I know "DES" is an encryption standard from the seventies and it's considered broken. Yup. Pretty much. Consider reencrypting it with AES like so: $ openssl rsa -in desencryptedprivkey.pem -out aesencryptedprivkey.pem -aes128 EDIT ...


2

To be clear, the data to be signed is exactly the contents of a file, XML or otherwise? You can't sign with only a certificate. You must sign with a privatekey and then provide the matching certificate to allow the recipient(s) to verify the message when they receive it. When using a certificate issued by a well-known CA (e.g. Verisign) you usually must ...


0

For static/fixed ECDH or static DH, like plain-RSA (akRSA), server proof-of-possession is implicit by having keyexchange correctly produce Finished. OpenSSL apparently indicates this by using the KX algorithm for the Au= algorithm, since there isn't really a specific algorithm used for authentication. Note OpenSSL implements static (non-EC) DH only very ...


1

Taken from RFC4492 Section 2.1 2.1. ECDH_ECDSA In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable public key and be signed with ECDSA. A ServerKeyExchange MUST NOT be sent (the server's certificate contains all the necessary keying information required by the client to arrive at the premaster secret). ...


3

What does this mean? The certificate changed, as shown by the different SHA1 hashes. The MD5 hash field is no longer relevant as Firefox deprecated them. Can I trust the certificate? No, if it changed without the admin (ie. your) intervention, you should be highly suspicious. How can I check that my certificate is still valid, created by me, ...


0

You can find some more information by "tapping" NET::ERR_CERT_AUTHORITY_INVALID on the first page see this example here: https://www.youtube.com/watch?v=o8iJE7p-W4M In short NET::ERR_CERT_AUTHORITY_INVALID indicates the certificate authority is not trusted by your Android device. Try opening a support case with the CA (Comodo), a quick google seems this is ...


1

You need a client certificate for each user (or client app if your app is authenticating to the server) that will use mutual auth SSL. You can purchase client certs from an existing CA or create a self-signed CA cert and issue your own certs. If you have many users, purchasing certs can be expensive.


1

The server certificate and the CA certificate used for authenticating your clients are two different things. First, you need to have your server certificate installed (SSLCertificateFile and SSLCertificateFileKey). You should already have that. At this point, you have your server presenting his certificate to clients. Now, you need to generate a CA ...


6

If the entity is supposed to sign CRL but not certificates, then it is not a CA -- it is a CRL issuer. It is often called an indirect CRL issuer because, by definition, it is distinct from the CA that issued the certificates whose revocation status is specified by the CRL. A certificate may be validated as a CA only if (among other things) it has a Basic ...


1

...despite the fact that openssl s_client does not? OpenSSL never checks the hostname against the certificate, but browsers do. ...openssl s_client -connect :443 ... I see that you are using s_client with the IP address and not the hostname. Since you claim to have the proper mapping between name an IP address in your hosts file using the hostname ...


1

You have provided insufficient details for us to answer the question. Exact browser error text might help indicate what the browser actually thinks is the problem Certificate details that are currently redacted might shed light The redacted s_client output tells us nothing except that TLS got negotiated, which we knew from the fact your browser gave you a ...


0

I'd say stick to secp521r1 - even DJB says P-521 is pretty nice prime, and it's also supported in every modern crypto library. In the same time, we should push forward adoption of non-NIST curves like Curve25519, which will be fully rigid, less prone to implementation errors and may become nice alternative for those who need faster solutions than secp521r1. ...


1

Based on link from DarkLighting, here's the command I came up with using nested subshells. openssl req -new -sha256 \ -key domain.key \ -subj "/C=US/ST=CA/O=Acme, Inc./CN=example.com" \ -reqexts SAN \ -config <(cat /etc/ssl/openssl.cnf \ <(printf "[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com")) \ -out ...


3

No, the only way to change the validity date is to re-issue. The reason is that the certificate's hash is calculated after the rest of the certificate is written, editing that field would cause the certificate's hash to change. If the hash is changed anyone else checking the certificate will know it has been altered, but won't be able to tell what changed. ...


4

No (EDIT: This was a much longer post. I was speculating about wildcards. Turns out: It's much simpler.) You can't do it. RFC 5280 says: When the subjectAltName extension contains an iPAddress, the address MUST be stored in the octet string in "network byte order", as specified in [RFC791]. The least significant bit (LSB) of each octet is the LSB of ...


1

Here's two client test sites. Just about SSL3: https://zmap.io/sslv3/sslv3test.html Comprehensive: SSL Labs (that you already mentioned yourself). You need to scroll down to the "Protocol Features" section: https://www.ssllabs.com/ssltest/viewMyClient.html


3

tl;dr: Yes. You need to use a proxy or VPN to hide the destination of your traffic forom your ISP. The Long Version: As described in this section of the IPv4 Wikipedia article, IP packets have a header section and a data section. The header section contains, among other things, the Source IP Address and Destination IP Address fields. These fields are ...


2

Your ISP will be able to see the IP you are connecting you even when using SSL. If you wish to mask the IP you are connecting to from your ISP, you can use a proxy or VPN to do so. You -> ISP -> VPN/Proxy -> Website That way the ISP can only see the IP of the proxy/vpn you are connecting to.


1

There is a variation of TLS that uses a Pre-Shared Key instead of certificates, called TLS-PSK. This basically works the same way as usual TLS except the session key is generated in a different way. You should take a look at this.


0

Though @Angel's answer is mostly correct, there can be details... In the SSL family of protocols (a family which includes SSL 3.0, as well as TLS 1.0, TLS 1.1 and TLS 1.2), there are about four places where a hash function may be used: In the "PRF", which is the function used for key derivation during the handshake and other similar usages. In SSL 3.0, ...


4

TLS 1.0 (SSLv3 successor) was published in January 1999 (RFC 2246). SHA-2 was first published in FIPS 180-2 in 2001. Thus, there's no way an implementation following just the SSL3 specifications could have supported SHA-2. The version used by SSLv3 would have been SHA-1, just like TLS 1.0: SHA The Secure Hash Algorithm is defined in FIPS PUB 180-1. It ...


2

As per this Blog by default, web servers including Apache will generate a single export-grade RSA key when the server starts up, and will simply re-use that key for the lifetime of that server. What this means is that you can obtain that RSA key once, factor it, and break every session you can get your 'man in the middle' mitts on until the server goes ...


2

The idea of the FREAK attack is that the attacker has already factored the RSA key -- because the server uses the same RSA key pair ever and ever (generating a new RSA key pair is somewhat expensive so the server won't do that for each connection). Since the attacker, at that point, knows the RSA private key, he can hijack the connection and "fix" the ...


1

Your decryption command is correct. It seems there's something wrong with your key file. Does it really start with -----BEGIN RSA PRIVATE KEY----- and end with -----END RSA PRIVATE KEY----- (mind the exact number of dashes)? Or is it perhaps DER encoded which requires you to add -keyform DER your decryption command line? BTW: You can check the integrity of ...


0

From the people who found the vulnerability Another online test These two give me conflicting answers. I think the researchers in link one report that your site as being vulnerable if there is any way in which it can be configured that will allow it to be exploited. Where as the second link shows the more pragmatic, "is it vulnerable right now?" ...



Top 50 recent answers are included