Hot answers tagged

62

It's a bad sign, but it is still very unlikely that the connection is being eavesdropped on. The website appears to have a valid certificate signed by a certificate authority, but it is signed with a weak and obsolete hash algorithm. What does that mean? It means the connection is encrypted and a passive eavesdropper can still not listen in. But a ...


20

As others have said, technically the risk is small for a MiM attack. However this has a larger problem and implication. Should I go ahead and enter my card details and pay for something on this site? IN NO WAY SHOULD YOU EVER USE THIS SITE FOR A CARD TRANSACTION Slight Revision - I was mistaken and and SHA-1 is allowed in some circumstances, though ...


15

It means that the certificate used by the site is using an outdated signature algorithm to confirm the certificate identity. Google has been aggressively targeting SHA-1 signatures for site certificates for a couple of years, since there are some theoretical attacks which could result in a fraudulent certificate having a valid signature, although there has ...


4

From the OpenVPN 2 Cookbook: The OpenSSL ca command generates its CRL by looking at the index.txt file. Each line that starts with an ' R ' is added to the CRL, after which the CRL is cryptographically signed using the CA private key. To reinstate your revoked certificate, you could edit your CA database: database = $dir/index.txt ...


4

No, it is not possible to determine the state of SSL pinning at the client. SSL pinning is part of the certificate validation done solely inside the client and the only feedback the server gets is if the validation succeeded (connection continues) or not (connection closed, maybe TLS alert). Also there is nothing fully reliable the server could to to "ask" ...


4

Those is publicly available information. They are contained in the certificate and you "leak" them to all clients. What exactly are you concerned about? Your certificate is meant to be public. Edit for the edited question: Yes, those things can make the life of an attacker easier. the CN can leak the naming scheme for the network the CA can leak ...


4

Changes to DNS aliases (CNAME) or IP addresses do not matter at all to certificate validation. All what matters is that the hostname as seen by the client (for example the name in the URL) matches the subject(s) of the certificate. This name will not change on any changes to the DNS. Often a DNS CNAME gets confused with a HTTP redirect. In the case of CNAME ...


3

... how it proves anything about my identity to the webserver? It does not. It only proves the identity of the server to you so that a man in the middle attack (where someone claims to be google.com) is not possible. If client identification is required (usually not) client certificates could be used. "The certificate is intended... Proves your ...


3

Why not register the certificate for a fully-qualified domain name, instead of for the IP address? Assuming you're running it as a server, and leave it running for good stretches of time, you'd visit the DNS provider, and change the mapping between IP address and domain name, only when you received a new IP address. Additionally you could request a static ...


3

The technical answer is actually "no, because SHA-256 with RSA-2048 Encryption is not a certificate hashing algorithm. However, SHA-256 is a perfectly good secure hashing algorithm and quite suitable for use on certificates, and 2048-bit RSA is a good signing algorithm (signing is not the same as encrypting). Using 2048-bit RSA with SHA-256 is a secure ...


2

From the github readme for the iOS SSL Kill Switch project: Once installed on a jailbroken device, iOS SSL Kill Switch patches low-level SSL functions within the Secure Transport API So your question basically boils down to: "How do I prevent my app from being infected with malware on a rooted / jailbroken device?". In short: you don't. This is why you ...


2

There is no point in trying to prevent this. Technically I guess you could slow down an attacker by implementing your own crypto (SSL Kill Switch modifies the OS-provided crypto functions) but even that will eventually get cracked given enough time and effort. If you don't control the hardware, your software has no chances. Just live with it and let people ...


2

It is probably that Firefox and Chrome decided to trust certificates on different levels. Chrome trusts "GlobalSign Root CA" and it chains certificate all the way up to root one to check its validity, but FireFox trusts "Trusted Root CA SHA256 G2" and there is no need for it to check all up to root one to tell you if that browser trust it. So if both ...


2

Yes, you can. You just need to have the private key in the proper format to be used by openssl. Not knowing in which format you exported, it's impossible to provide commands, but -supposing it can't sign directly with it- openssl x509 may be able to convert the file.


1

Others have noted the problems getting the card info to the site, but you must also think about how they handle that information internally. I once worked at a dotcom that stored credit card info in our database in plain text. Anyone with access to client info could see them. Lazy certification is only the tip of the iceberg, IMO.


1

The most logical solution is to place the name in the subject of the certificate, and use dynamic DNS to make the name point to the same raspberry PI. Of course, one would need a DNS server. If you can use IPv6 and having a DNS server is too much work, with it the Rasbperry would have a fixed address automatically with stateless autoconfiguration (based on ...


1

Your question isn't very clear, but answering one possibility: The KeyStore API abstractly and the JKS format concretely has two kinds of entries relevant to SSL/TLS: the privateKey entry for a server contains the privatekey and the cert chain (leaf and intermediate(s) and usually root) all under one alias; trustedCert entries (if any) contain certs for ...


1

in a keystore/trustore you can have more keys/certificates and every key has an alias. If you have to configure the SSL in a server, usually you configure the keystore, the keystore-password, the key password and the alias. Basically with the alias you refer which key you intend to use. example with jboss wildfly 8 < security-realm ...


1

GlobalSign has three active root CAs of which two have a CommonName of simply GlobalSign, although other name components are different if you look at the details. Root-R1: CN = GlobalSign Root CA, OU = Root CA, O = GlobalSign nv-sa, C = BE valid 1998/09/01 to 2028/01/28 sha1 fingerprint b1 bc 96 8b d4 f4 9d 62 2a a8 9a 81 f2 15 01 52 a4 1d 82 9c Root-R2: ...


1

The SIM Card is not able to fulfill the requests sent to it when trying to place a certificate on it. The required commands are not available. Most (nearly all) SIM-Cards are not able to be extended in functionality either.


1

In your question you are only taking about keys, where a key can signed by someone else but the key is not associated with an identity itself: If John also has a key signed by Peter, presents it to Bob, Bob verifies, but John says that his username is Alice, than what to do? You then propose the concept of adding the identity: Is it ok if Peter ...


1

From my understanding your problem is that an active man in the middle can make a server S access a URL at host U and this URL is specified by the attacker. And the problem with this is not that the attacker might get to the contents behind this URL (he can't) but that just accessing this URL might trigger a bug at the server U. Thus to make this attack ...


1

In general, certificates are meant to be public. The idea of a certificate containing secret information doesn't really make sense. That being said, the certificate does contain information about the topology of your intranet (domain names of the servers, CN of your internal CA, etc). Maybe this gives attackers an advantage, maybe it doesn't. If your ...


1

You got the wrong certificate. Check the graph at the Let's encrypt site and you will see that a leaf certificate is not signed by the X1 certificate you've downloaded but by X3. If you would look at the certificate details (with openssl x509 -text or similar) you would also see the issuer of your certificate and you could check that it matches the subject ...


1

This here will be human readable. And (thanks to the semicolon as the delimiter) it will also open nicely in Excel: dir cert: -Recurse | where {$_.subject -ne $null} | where {$_.subject -eq $_.issuer} | Export-Csv -NoTypeInformation -Encoding UTF8 -delimiter ';' -path selfsignedcerts.csv


1

As to the first part of your question. the answer is NO, and all who say it is forget that that also means breaking essential layers of security on the device. as to the second it is possible but highly dubious to do so. The way to do this is by buying a certificate for a domain (like localapp.example.com) and have its DNS entry point to 127.0.0.1. and ...


1

Reading the X.509 recommendation tells us that a certificate can be "un-holded" by 2 means: either really revoke it, by changing the reason code while keeping the date or completely remove it from the CRL. If you plan to issue deltaCRLs, you MUST use the "removeFromCRL" reason code for such certificates, only for the deltaCRLs.


1

Android requires app updates to be signed by the same key as the original app. So unless the developers themselves have been compromised, a MITM won't be able to update existing apps. Note that this process is completely unrelated to SSL certificates. App signing certificates are self signed and don't rely on certificate authorities for trust. It sounds ...



Only top voted, non community-wiki answers of a minimum length are eligible