I have another question to security in the web.
If I understand it correctly certificates are for identify who you really are. So the man in the middle attack isn't possible.
But when I see this image:
http://upload.wikimedia.org/wikipedia/commons/thumb/2/2b/Digital_Signature_diagram.svg/800px-Digital_Signature_diagram.svg.png
I think a man in the middle attack is possible. You could split the Signature, the certificate from the data. Make your own signature with your fake data and send the fake data with the fake signature (but the right certificate) to the server/client.
What I also not understand in this picture is where the certificate gets checked, on the verification side.
thanks.
SCBoy
Make your own signature with your fake data and send the fake data with the fake signature (but the right certificate) to the server/client.
The problem is that the receiver will then look at the fake signature and see that it does not match the certificate of the real sender.
You can only create signatures that match a given certificate when you have the correct private key for that certificate (even though the certificate itself is public, that is the magic of asymmetric cryptography). This private key is being kept secret by the owner of the certificate (the original sender of the message).
The man-in-the-middle is prevented by distributing trusted certificates in advance.
You have to trust the authenticity of the certificates, either by trusting them directly (root certificates) or by trusting a chain of signatures on the certificate leading up to one that you trust.
If the man in the middle can make you believe that his fake certificate is the real deal, then the whole system fails.
Related
I want to offer the user the option to sign a PDF by using a digital certificate.
Administration nowadays provide you with a certificate that you can use to sign in their gob related sites and also to sign PDF documents.
I know how to sign a document by using FPDI library, but I do require the certificate file first.
I guess I can always request them to upload the certificate itself as a normal file, but that wouldn't make much sense, as they would also require to share their certificate password (if any) with me.
I would like my site to pop up something like the below to get their signature / certificate - is that possible?
I got the error NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM when accessing one website using Chrome browser on macOS. The url of the website is corporate / internal so I can't paste the url here (you won't have access anyhow).
Chrome version 75.0.3770.142.
macOS version is Mojave (10.14.4).
Chrome devtools Security tab show 2 errors:
Certificate - insecure (SHA-1) : The certificate chain for this site contains a certificate signed using SHA-1.
Certificate - missing : This site is missing a valid, trusted certificate (net::ERR_CERT_WEAK_SIGNATURE_ALGORITHM).
I can bypass the warning, but it come back after each page change/page refresh (so boring).
I know why the warning 1 is shown: the leaf certificate is signed with a certificate which signature algorithm is SHA-1 with RSA. Chrome detects this as weak. (I'm ok with this behavior)
I guess the warning 1 implies the warning 2: the leaf certificate can't be trusted.
The things I don't understand are:
why I don't have the problem using Firefox, on the same macOS computer
why I don't have the same problem using Chrome, same version, from another macOS computer
why I don't have the same problem using Chrome, same version, from a Windows computer
As a side note, Chrome on Windows computer show the same Certificate - insecure (SHA-1), but the warning 2 ERR_CERT_WEAK_SIGNATURE_ALGORITHM is not present.
This drives me crazy !
Does anyone have an idea on this ?
Does anyone knows how/when/why those warnings are raised ? (I may look into Chromium source code but I don't know if Chromium handles this mecanism)
I really don't understand why there are such different behavior on configurations that looks similars...
Thanks for your help,
Romain
The URL is corporate, so the certificate is signed by your corporation. This is normal for many corporative sites/intranets.
Chrome assumes SHA1 is weak, but this is OK. It is the company certificate for the corporative intranet (i am assuming it is an intranet URL, or alike), so no problem it uses SHA1.
The site is missing a valid trusted certificate, means the current URL certificate could not be validated by any worldwide authority (this is normal, it was created by the intranet admin, internally, for internal use), and then the message is warning you that it is not trustable: Not trustable here means your computer does not know what to do, it tried check it to validate via internet if it could be trusted but it couldn't find any authority who replied, so the warning is for you to take some action (ignore, avoid the url, check the certificate, or trust it)
Solution:
On MacOS you have to add that certificate to the KeyChain, this way you are intentionally telling the operating system and any application who need to verify the certificate that it is trustable.
To do it:
open the certificate by clicking "View Certificate" on Chrome (like it is on your image above)
Once it is opened, click on its square drawing (difficult to explain this, I will put a picture below), and
Drag the certificate to your desktop (or any folder, this is temporary)
Go to finder, double click the certificate you just saved, you will se a dialog box like the image below:
Click Add (keychain must be login, like the above image)
Keychain Utility should open automatically at this point, if it doesn't, open KeyChain Utility on your Mac. Locate the certificate inside the Login Keychain (example picture below)
You'll see it was added, but yet not trusted. So we will tell the system we trust it, and by trusting it applications like Chrome and Safari will not display that warning anymore. Because they will check that the system trust that certificate for SSL connections.
Double Click it on the Keychain, it will open, click the little triangle to expand "Trust" item.
Select the item "Secure Sockets Layer (SSL)", and put the value "Always Trust"
Close the certificate by clicking on the red X button on its window. It will ask for your password to save the new settings for the certificate.
Put your password, click Update Settings
It will now show a blue icon, along with a message telling it is marked as trusted for your account.
This is it.
The Chrome messages will disappear because now that certificate is trusted.
Note: You may be thinking now... "I never did it on the other Mac" and you explained that you don't have that problem on Chrome on that other Mac. I suppose on the other Mac you have accessed that corporative URL using Safari at least once. When you access via Safari it will present you a similar warning like Chrome does, but if you ACCEPT it on Safari, it automatically does all this tutorial procedure for you transparently: it just ask if you want to proceed anyway, you click "proceed", Safari asks you for your password then it put the certificate on the keychain and mark it as trusted [exactly like we did] but transparently. And the next time you access the corporate URL you will not be asked because its certificate is already trusted on your keychain. Later if you then access it using Chrome it will not ask you, because it will see that the keychain already has that corporate certificate as trusted.
This is very probably why your other Mac does not have this situation.
PS: I could have answered here just: Access it using Safari, accept and proceed, and it will never ask again. But this would not be the correct answer. It would not explain the reason, and would be out of your presented scenario. So since you are using Chrome, I described this procedure considering the exact application and the exact situation that you have presented here, clarifying the reasons behind it.
Of course, now, since you know there is 2 ways to make this certificate installation procedure, you can opt for the one you like better.
_
Note: as mentioned by #patrick-mevzek
"On MacOS you have to add that certificate to the KeyChain", and you
will need to to it again each time the certificate changes or is
renewed. And if signed by a private CA, and if you add the CA in the
trust store, you are then open to various MitM attacks, as this CA can
sign certificates for any name, which is/may typically be the standard
setup inside corporate PKIs, but you have to be aware of consequences.
"
I agree with #patrick-mevzek, he is right and he made an important observation on this topic.
I'm extending the point he mentioned (specifically for MacOS) by showing how you can check if the corporate certificate you are about to add to your keychain is a CA Certificate or just a common innofensive end-to-end SSL certificate.
Open that certificate again, scroll down the information of it, until you find the item "usage" as shown on the picture below.
On the image below, there are 2 kind of certificates:
on the left, there is a CA Certificate: it can be used as MitM decryptor if your company wanted. It would only require a proxy between you and the internet, where your browser traffic would passes through. And if you have this kind of certificate trusted on your keychain, you have to be aware that the company proxy can (if a malicious admin wanted) decrypt your encrypted HTTPS traffic and log every confidential information on your connection to anywhere.
on the right, there is a simple and common SSL Certificate used by all of websites and internet domains, its purpose is just end-to-end encryption between you and the visited domain, to encrypt your traffic. It cannot be used as a MitM decryptor of your connection traffic data. This kind is totally safe to be trusted on your keychain.
Let's consider that you have the dangerous case, which the certificate is a CA Certificate and you added and trusted it.
Is there a way for you to know if your traffic is being decrypted by your company and your information being exposed?
Yes, there is.
On any browser, when you are accessing any important site, choose a bank for example, for this example I am choosing "hsbc.com.br", and I will show both situations:
The normal end-to-end encryption as it always must be
The MitM situation decrypting the banking sensitive private data.
While accessing any important https site, even if you see the Green icon on chrome or safari telling the connection is encrypted, check the certificate of it if you want to be sure that nobody is in the middle.
_
Here is the normal & SECURE situation:
HSBC Certificate is issued by DigiCert Inc and also is of type EV, which offer stronger guarantee of identity.
Now lets put a proxy in the middle, and do the MitM atack.
Here is the same HSBC bank I just acessed minutes ago, but I inserted a MitM proxy technic on my network, and I trusted that kind of certificate [CA Certificate] on my MacOS keychain.
Let's see what Chrome tells about the banking website:
It is telling me that it is secure, and also says that my information will be private!
But Chrome is WRONG!! (And it doesn't know it is wrong, because it is beyond it)
Lets open the certificate again: (I just activated the proxy and reloaded the page)
It is easy to notice the difference, the fake HSBC certificate was issued by my own personal certificate authority inside my network. This was done automatically by my proxy, which is capable of reading all the information I insert on the HSBC bank website, in pure TXT format, in both ways. Then it encrypts the data again and send to my Browser, and vice versa, do the same re-encryption while talking to HSBC servers.
The browser "think" that everything is OK, because the connection is encrypted, the site name on the certificate MATCHES the URL address I am accessing, the certificate is valid, and the CA Authority it is trusted on my keychain!
Everything technically is fine, except that is not.
This is the real danger, exposed, as mentioned by #patrick-mevzek that you have to be aware.
I have 2 code signing certificates, for both CSR is created same way, also import and export is done same way. The only difference that I see is that one of certificates Common name contains Quotes, and the other doesn't.
e.g.
some cert and
some "cert"
CSR creation
Request format PKCS #10
disabled "Strong private key encryption"
Entered Common name, Organization, Locality, State, Country
2048 bytes for private key
set private key exportable
Import
place all certificates in Personal store
Export
Include all certificates if possible
Enable certificate privacy
encryption algorithm TripleDES-SHA1
Misleading thing is that this Common name value is NOT taken from the value I entered when I created CSR request
I am using those certificates to sign Winforms applications in Visual Studio. Certificate without Quotes in common name is working correctly (i.e. when I install application user is not getting security warning about unknown publisher), but when I install application which is signed with the other Code signing certificate (with Quotes in Common name) - it does not recognize Publisher. No error when published my application. When I take a look at setup.exe properties in Windows Explorer I see a Digital signatures tab which contains row for my certificate.
I tried to sign files with signtool and then verify - it said that certificate is valid.
I tried to get help from godaddy.com where I bought my certificate, they said that it should work with quotes, too, but didn't offer help to solve the issue. Rekey also didn't help.
I see that there are some suggestions to use Pre Publish, Post Build tasks, but I am not using those for my first certificate which is working.
So, is anyone here using code signing certificate for Winforms application with common name having quotes in it? Or maybe anyone knows about this problem and how to solve it?
Had to revoke (common name which is entered when creating CSR is not taken into account, so rekeying is not enough!) my code signing certificate and create from start without quotes/brackets in company name.
So this means, you will have to wait again for few days, because verification process is made from start again. When you will be contacted by issuer, they will verify / ask you about company name - make sure that they do not include quotes/brackets.
Revoking means that you will basically have to buy your certificate once more, because after you revoke it (at least in godaddy case) in your account you don't have options to create it again. So, you have to contact support (use call center and not chat ;)
I'm working on a .NET PDF signature application that allows signing with a SmartCard (Belgian ID). In addition, I'd like the signature to support LTV.
I've followed the instructions and examples from iText, and it seems to work well. Acrobat Reader DC indicates that the signature is valid, and offers LTV.
There is an practical issue however: the included CRL is too big. 14MB on my test ID. This means that, for every signature, 14MB needs to be downloaded which slows down operation and significantly increases the file size of each signed PDF.
I was wondering if there is an alternative to including the complete CRL while still supporting LTV? It seems a bit overkill to include the complete CRL while the only "thing" that seems needed is the inclusion of a verifyable proof that the certificates in the chain have not been revoked at time of signing. I thought that use of the OCSP might offer such functionality, however simply removing the CRL and including a OcspClientBouncyCastle instance didn't do the trick. Is the OCSP that is given to SignDetached used to check whether the certificate is revoked at time of signing instead?
A related question concerns the LTV "support" itself. As I mentioned, Acrobat Reader only indicates that the file supports LTV when the CRL is included. Checking at the online service http://dss.nowina.lu/validation (EU reference) seems to indicate something else however. There, even the file without the embedded CRL has a valid check behind the description "Is AdES-T validation conclusive?" (which is the only checkpoint under "Long Term Validation Data"). As such, I was wondering if it is even needed to include the CRL for LTV?
Suffice to say I'm confused :).
Btw, 2 more warnings from that same verification service that I can't seem to solve: "The 'issuer-serial' attribute is absent or does not match!" and "The signer's certificate is not supported by SSCD!". But maybe thats for another question.
Thanks in advance for any help.
I had a look at your sample document. It does not conform to any LTV profile, merely to T-Level, i.e. it is timestamped.
In detail
The PDF signature is implemented merely by embedding a single CMS container using subfilter ETSI.CAdES.detached which contains
the certificate chain of the signer certificate in the CMS container certificate set
C=BE,CN=Belgium Root CA2
C=BE,CN=Citizen CA,SERIALNUMBER=201103
C=BE,CN=Donny Tytgat (Signature),SURNAME=Tytgat,GIVENNAME=Donny Geert,SERIALNUMBER=81032305309);
a signed Adobe RevocationInfoArchival attribute containing a single good OCSP response for the signer certificate; the response is signed by
CN=Belgium OCSP Responder,C=BE
which has the id-pkix-ocsp-nocheck extension;
a signature time stamp signed by
C=BE,SERIALNUMBER=2014,O=Belgium Federal Government,CN=Time Stamping Authority
Thus, the signature conforms to Baseline T-Level as
A PAdES signature conformant to T-Level shall be a signature conformant to B-Level for which a Trust Service
Provider [i.4] has generated a trusted token (time-mark or time-stamp token) proving that the signature itself actually
existed at a certain date and time.
(section 7 - Requirements for T-Level Conformance - ETSI TS 103 172 V2.2.2)
where B-Level conformance is defined as
This clause defines requirements that PAdES signatures claiming conformance to the B-Level have to fulfil.
The current clause specifies compliance requirements for short-term electronic signatures.
This clause actually profiles
PAdES-BES (signatures that do not incorporate signature-policy-identifier) and PAdES-EPES (signatures
that do incorporate signature-policy-identifier) signatures.
(section 6 - Requirements for B-Level Conformance - ibidem)
(Additional requirements also are fulfilled.)
It does not conform to LT-Level which requires:
The generator shall include the full set of revocation data (CRL or OCSP responses) that have been used in the
validation of the signer, and CA certificates used in signature. This set includes all certificate status
information required for validating the signing certificate, for validating any attribute certificate present in the
signature, and for validating any time-stamp token's signing certificate (i.e. a TSA certificate) already
incorporated to the signature.
(section 8 - Requirements for LT-Level Conformance - ibidem)
as there is no revocation information concerning the CA certificate or the TSA certificate.
Thus, it can also not conform to LTA-Level as
A PAdES signature conformant to LTA-Level shall be a signature conformant to LT-Level to which one or more
document-time-stamp has been incorporated
Concerning other questions
I was wondering if there is an alternative to including the complete CRL while still supporting LTV? It seems a bit overkill to include the complete CRL while the only "thing" that seems needed is the inclusion of a verifyable proof that the certificates in the chain have not been revoked at time of signing. I thought that use of the OCSP might offer such functionality
Given an appropriate PKI infrastructure that is possible. Unfortunately, though, neither the CA not the TSA certificate contain information on a OCSP responder responsible for them. Thus, either the Belgium citizen PKI does not provide OCSP services for those certificates or it merely does not make that provision public.
BTW, this is what the Diagnostic Tree remarks
<Message Id="0">OSCP Uri not found in certificate meta-data !</Message>
are about which you get when verifying your signature using the http://dss.nowina.lu/validation service.
There, even the file without the embedded CRL has a valid check behind the description "Is AdES-T validation conclusive?" (which is the only checkpoint under "Long Term Validation Data").
This user interface layout has misled you, as mentioned above there are more requirements for LTV-related profiles.
I have a server (RoR app) sending information to a client (a Ruby Sinatra app) and I need a way for the client to be certain the data has come from my server, rather than an evil third party.
The client has to login to the server before anything will be sent back the other way so the server could reply to the login with a shared key used to sign all further responses, but then the 3rd party could capture that response and be evil.
I'd like to find some way (in Ruby, with a view to cross-platform applicability) to sign the server's response so that it can be verified without inspection of the client's code leading to forgeries. Any ideas?
UPDATE: Lets see if I can explain this better!
(I've added code to github since I wrote this question, so you can (if you like!) have a poke around : The 'client' The 'server')
The process is this: Joe Bloggs uses a bookmarklet on his mobile device. This posts the currently visited URL to sitesender.heroku.com. When sitesender.heroku.com receives that request it checks its DB to see if anyone has logged into the same account using the Target application. If they have, their IP address will have been noted and sitesender.heroku.com will make a GET request of the target app (a webserver) at that IP asking the target to lanch the bookmarked URL in the default browser.
The basic idea being that you can send a site to your main computer from your iPhone for later viewing when you find the iPhone can't cope with the page (eg. flash, screen size).
Obviously the major issue is that with an open server anyone could send a request to open 'seriouslyevilwebsite.com' to a broad range of IPs and I've unleashed a plague on the digital world. Seeing as I'm using heroku.com as a server (its an incredibly good but cloud based RoR host) I can't just test the originating IP.
As far as I understand HTTPS, for this setting I'd have to sort out certificates for every target application? I agree that I need some form of asymmetric crypto, sign the outgoing requests from sitesender.heroku.com with a private key (never distributed) and get the target to perform the same operation using the public key and test for similarity - but you've guessed correctly, I'm still slightly clueless as to how HMAC works! How is it asymmetric? Is it formulated so that performing the same HMAC operation with the private key and public key will generate the same signature? In which case - HMAC is a winner!
Thanks for your patience!
I'm not sure exactly what you mean by "freely examined, but not replicated".
In general, if you need a secure communications channel, https is your friend.
Failing that (or if it's insufficient due to some architectural issue), HMAC and asymmetric crypto is the way to go.
UPDATE: I'm not sure I understand the problem, so I will try to describe the problem I think you're trying to solve: You have clients that need to be confident that the response they are seeing is actually coming from your server.
Assuming that I'm correct and this is really the problem you're trying to solve, HTTPS solves it nicely. You install a cert on your server—you can sign it yourself, but clients won't trust it by default; for that, you need to buy one from one of the standard certificate authorities (CAs)—and then the client makes an HTTPS request to your server. HTTPS handles verifying that the provided certificate was issued for the server it's talking to. You're done.
Finally, I think there's a misunderstanding with how an HMAC works. The key principle of asymmetric crypto is to NEVER distribute your private key. With asymmetric crypto, you encrypt messages with the recipient's public key and he/she decrypts it with his/her private key. You sign messages with your private key, and he/she verifies it using your public key.