1I have an app installed on my android device that shows me if the SHA256 fingerprint has been changed. It often shows that it has been altered when I run it for YouTube.com and it once showed for Instagram.com. I tried using a VPN and it didn't show afterwards.
The app basically says that it detects the SSL interception of web traffic which will decrypt an encrypted session. The test is accomplished by comparing the HTTPS certificate fingerprint of the website on your device vs the fingerprint shown on an external server.
I'm curious if it is really a concern as I do a lot of private video calls on Instagram. Are those getting recorded or anything without my knowledge?
PS: I do not have any shady app on my device.
Check the actual certificate the sites return. Certificates will expire after a while, meaning they get replaced with new versions.
Besides that, bigger sites with multiple datacenters, such as YouTube (Google) and Instagram (Facebook), might even use different certificates for different regions. This would explain why it doesn't show up while using a VPN. Also because of IP routing, special server configurations, ... you might end up connecting to different servers/regions (with different certificates) from day to day or so.
Assuming that the certificate is properly signed, valid and not revoked, you should be fine, even if the fingerprint changes. For malicious people to perform a man-in-the-middle attack with a valid SSL, they'd either need to have a valid certificate themselves (which would get revoked), access to the site's servers (which is a lost cause) or add a malicious root certificate to your device (which is a whole other problem).
The test is accomplished by comparing the HTTPS certificate
fingerprint of the website on your device vs the fingerprint shown on
an external server.
Mind that that external server might also have a different/outdated fingerprint compared to you, for any of the reasons above or others.
Consider we run the following request:
url="https://secretsub.example.com/secretpath/post.php"
payload = {'secretmessage1' : 'foo','secretmessage2' : 'bar'}
r = requests.post(url,data=payload,verify=True)
The language (python) is just arbitrary but it can be a request on any other language (NodeJs, Java, Php...)
Notice that the url is using https, which means that the connection is secured over SSL. Assuming that I compile this program into binary (.exe), would it be possible for computer to read the payloads through a software in plain text?
I know that packet sniffing software (like WireShark), will only reveal the domain name (example.com) in plain text but not the secrepath nor the payload which will be encrypted.
If I run this code in a web browser however (assuming that it is written in Javascript), I will be able to access the payload and the secretpath in plain text inside the browser console. I assume that the browser only encrypts it only after the request is logged in its console. But if this code is run outside the browser, is there a way a for the computer host to intercept those data in plain text? (some sort of packet sniffing tools)
It is only possible to see the domain name, the payload and path are encrypted and can only be decrypted by the session key as negotiated between the client and webserver. But malware on your computer could be able to access it, for instance by having access to the memory used by the application or by using an insecure programming library with some kind of backdoor.
What the https is doing is initiating a certificate exchange so your client will recieve a certificate from the server that validates the server is who thay say they are and allows the client to encrypt the data through the channell (network).
The first bit - validating the server is who they claim to be - relies on something called a certificate chain. The certificate you recieve will have been signed with an issuers private key. Your client should check this certificate using the issuers public key that you should "already have".
Most operating systems have a list of trusted root certificates. In windows you can see them in the certificate manager.
Without knowing python - #Patrick Mevzek hints that you can ship a root CA (certificate authority) or use the OS one. if your using the OS one - you might need to check its going to be there.
I would expect all this to be automatic - its part of the protocol that you've specified i.e. https. However - you might want to confirm that with a python person.
Most people kind of ignore all this bit - but it is very important. If you do not validate the certificate then you are susceptabe to a "Man in the Middle" attack or DNS spoofing.
Basically I can issue a cert for secretsub.example.com using a couple of tools on my desktop. It will not be signed by a valid CA but if you don't check it then I can either place that cert in a proxy (Man in the Middle) - and when you make your requet my proxy will get the real cert from the real server, establish the HTTP connection but issue my cert to your application. You will then encrypt to my proxy with my cert so I can read your data and then forward it to the real server - and you'll never know! (Many corporate proxies do exactly this to their employees).
Alternatively if I can change your DNS to point the IP to my server I can do pretty much the same - act as a proxy.
Once that's done the data will then be encrypted accross the network.
So - yes HTTPS will encrypt accross the network - but check the cert is valid.
Obviously as someone points out - the data is in the clear on the client computer - just like it is in your browser now.
Stuart
I am using the Authorize.Net DPM (Direct Post Method) integration on one particular eCommerce system that I manage.
We have renewed our SSL certificate for this site, and the new SSL cert uses SHA-256 rather than SHA-1, as is recommended for additional security.
However, now AUthoeize.Net can no longer post back to my server. When processing a payment, I receive the message:
An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.
from the URL https://secure.authorize.net/gateway/transact.dll, rather than being sent back to my code where I can display the "payment successful" page. Upon reseraching this, I believe the issue is that Authorize.Net's servers don't support SHA-2 certificates:
Does anyone know if Authorize.net accepts the newer SHA2 encryption? Our production servers which use this type of certificate do not receive the RelayResponse.
We found an article on SHA2 encryption issues with WIN2003 servers KB968730. We know Authorize.net uses Win 2003 servers based on http headers, which tell us IIS6.0.
We just established that is a real issue with Authorize.Net. We were able to purchase a SHA1 certificate and we are now able to receive the Relay Response from Authorize.NET. Authorize.NET Relay Response does not handle G2/SHA256 certificates. This will become a major issue in 2014 when SHA1 certifictions will not be obtainable from vendors eg. GoDaddy etc.
I have contacted Authorize.Net support but they seem to not even understand how their own product works, because the responses I get from them make no sense:
We have no announcements regarding the use specifically of SHA-2 hashes to connect to our servers at this time. Notices of any changes to the integration methods will be available in the merchant interface, as well as on the developer center at developer.authorize.net if that change occurs.
I'm not connecting to their servers. They're connecting to my server... so since their support is of no help... how can I resolve this? Is it safe/wise to not use SSL for the x_relay_url DPM postback URL? That seems to be the safest suggestion but I am hesitant to do this.
The resolution I went with was to get an SSL certificate with an SHA-1 signature algorithm, rather than SHA-2.
The issue that SHA-2 certs are rejected by Authorize.net's servers has been reported to their systems engineering team, but I do not know if they will correct this.
I have just run into this problem myself.
I can verify that in my tests, when I switched my x_redirect_url parameter to use a non-ssl host it started redirecting properly back to my site. I can also verify that Authorize.net support does not know how their own products work; I had to explain to them how the x_redirect_url works and got no usable info from them regarding any kind of validation they might be doing on the redirect URL that could cause their system to refuse to redirect.
I thought it was due to a domain name mismatch in my dev environment so I just forced my dev environment to use a non-ssl redirect. Then when I launched my new site I discovered that the problem persisted with SSL redirects on my production site, so I've just switched it back to using non-ssl redirects on my production site temporarily until I get this sorted out.
I have not yet regenerated my ssl cert because I'm not sure if it's using SHA1 or SHA2 and I don't want to regenerate it and reinstall it until I'm sure the cert is SHA1.
I'm having a hard time determining which SHA version it uses because the Thumbprint Algorithm shows SHA1, but then I see SHA256RSA for the Signature Algorithm and sha256 for the Signature Hash Algorithm. So, if anyone knows if that means I have SHA1 or SHA2, please reply to this reply.
When faced by an untrusted certificate, every single browser I know displays a blaring error like this:
Why is that?
This strongly discourages web developers to use an awesome technology like SSL out of fears that users will find the website extremely shady. Ilegitimate (ie: phishing) sites do fine on HTTP, so that can't be a concern.
Why do they make it look like such a big deal? Isn't having SSL even if untrusted better than not having it at all?
It looks like I am being misunderstood. I am taking issue with the fact that HTTP sites cannot be more secure than an HTTPS site, even if untrusted. HTTP doesn't do encryption or identification. Phishers can make their sites on HTTP and no warnings are shown. In good faith, I am at the very least encrypting traffic. How can that be a bad thing?
They do that because a SSL certificate isn't just meant to secure the communication over the wire. It is also a means to identify the source of the content that is being secured (secured content coming from a man in the middle attack via a fake cert isn't very helpful).
Unless you have a third party validate that you are who you say you are, there's no good reason to trust that your information (which is being sent over SSL) is any more secure than if you weren't using SSL in the first place.
SSL provides for secure communication between client and server by allowing mutual authentication, the use of digital signatures for integrity, and encryption for privacy.
(apache ssl docs)
Yep, I don't see anything about third party certificate authorities that all browsers should recognize as "legit." Of course, that's just the way the world is, so if you don't want people to see a scary page, you've got to get a cert signed by someone the browsers will recognize.
or
If you're just using SSL for a small group of individuals or for in-house stuff, you can have people install your root cert in their browser as a trusted cert. This would work fairly well on a lan, where a network admin could install it across the entire network.
It may sound awkward to suggest sending your cert to people to install, but if you think about it, what do you trust more: a cert that came with your browser because that authority paid their dues, or a cert sent to you personally by your server admin / account manager / inside contact?
Just for shits and giggles I thought I'd include the text displayed by the "Help me understand" link in the screenshot in the OP...
When you connect to a secure website, the server hosting that site presents your browser with something called a "certificate" to verify its identity. This certificate contains identity information, such as the address of the website, which is verified by a third party that your computer trusts. By checking that the address in the certificate matches the address of the website, it is possible to verify that you are securely communicating with the website you intended, and not a third party (such as an attacker on your network).
For a domain mismatch (for example trying to go to a subdomain on a non-wildcard cert), this paragraph follows:
In this case, the address listed in the certificate does not match the address of the website your browser tried to go to. One possible reason for this is that your communications are being intercepted by an attacker who is presenting a certificate for a different website, which would cause a mismatch. Another possible reason is that the server is set up to return the same certificate for multiple websites, including the one you are attempting to visit, even though that certificate is not valid for all of those websites. Chromium can say for sure that you reached , but cannot verify that that is the same site as foo.admin.example.com which you intended to reach. If you proceed, Chromium will not check for any further name mismatches. In general, it is best not to proceed past this point.
If the cert isn't signed by a trusted authority, these paragraphs follow instead:
In this case, the certificate has not been verified by a third party that your computer trusts. Anyone can create a certificate claiming to be whatever website they choose, which is why it must be verified by a trusted third party. Without that verification, the identity information in the certificate is meaningless. It is therefore not possible to verify that you are communicating with admin.example.com instead of an attacker who generated his own certificate claiming to be admin.example.com. You should not proceed past this point.
If, however, you work in an organization that generates its own certificates, and you are trying to connect to an internal website of that organization using such a certificate, you may be able to solve this problem securely. You can import your organization's root certificate as a "root certificate", and then certificates issued or verified by your organization will be trusted and you will not see this error next time you try to connect to an internal website. Contact your organization's help staff for assistance in adding a new root certificate to your computer.
Those last paragraphs make a pretty good answer to this question I think. ;)
The whole point of SSL is that you can verify that the site is who it says it is. If the certificate cannot be trusted, then it's highly likely that the site is not who it says it is.
An encrypted connection is really just a side-benefit in that respect (that is, you can encrypt the connection without the use of certificates).
People assume that https connections are secure, good enough for their credit card details and important passwords. A man-in-the-middle can intercept the SSL connection to your bank or paypal and provide you with their own self-signed or different certificate instead of the bank's real certificate. It's important to warn people loudly if such an attack might be taking place.
If an attacker uses a false certificate for the bank's domain, and gets it signed by some dodgy CA that does not check things properly, he may be able to intercept SSL traffic to your bank and you will be none the wiser, just a little poorer. Without the popup warning, there's no need for a dodgy CA, and internet banking and e-commerce would be totally unsafe.
Why is that?
Because most people don't read. They don't what what https means. A big error is MANDATORY to make people read it.
This strongly discourages web developers to use an awesome technology like SSL out of fears that users will find the website extremely shady.
No it doesn't. Do you have any evidence for that? That claim is ridiculous.
This strongly encourages developers and users to know whom they are dealing with.
"fears that users will find the website extremely shady"
What does this even mean? Do you mean "fears that lack of a certificate means that users will find the website extremely shady"?
That's not a "fear": that's the goal.
The goal is that "lack of a certificate means that users will find the website extremely shady" That's the purpose.
Judging from your comments, I can see that you're confused between what you think people are saying and what they are really saying.
Why do they make it look like such a big deal? Isn't having SSL even if untrusted better than not having it at all?
But why do they have to show the error? Sure, an "untrusted" cert can't be guaranteed to be more secure than no SSL, but it can't be less secure.
If you are solely interested in an encrypted connection, yes this is true. But SSL is designed for an additional goal: identification. Thus, certificates.
I am not talking about certs that don't match the domain (yes, that is pretty bad). I am talking about certs signed by authorities not in the browser's trusted CA's (eg: self-signed)
How can you trust the certificate if it is not trusted by anyone you trust?
Edit
The need to prevent man-in-the-middle attacks arises because you are trying to establish a privileged connection.
What you need to understand is that with plain HTTP, there is absolutely no promise of security, and anyone can read the contents passed over the connection. Therefore, you don't pass any sensitive information. There is no need for a warning because you are not transferring sensitive information.
When you use HTTPS, the browser assumes you will be transferring sensitive information, otherwise you would be using plain HTTP. Therefore, it makes a big fuss when it cannot verify the server's identity.
Why is that?
Because if there's a site that's pretending to be a legit site, you really want to know about it as a user!
Look, a secure connection to the attacker is no damn good at all, and every man and his dog can make a self-signed certificate. There's no inherent trust in a self-signed cert from anyone, except for the trust roots you've got installed in your browser. The default set of trust roots is picked (carefully!) by the browser maker with the aim that only CAs who only act in a way to secure trust will be trusted by the system, and this mostly works. You can add your own trust roots too, and if you're using a private CA for testing then you should.
This strongly discourages web developers to use an awesome technology like SSL out of fears that users will find the website extremely shady. Ilegitimate (ie: phishing) sites do fine on HTTP, so that can't be a concern.
What?! You can get a legit certificate for very little. You can set up your own trust root for free (plus some work). Anyone developing and moaning about this issue is just being lazy and/or over-cheap and I've no sympathy for such attitudes.
Ideally a browser would look for information that you want kept secure (such as things that look like credit card numbers) and throw that sort of warning up if there was an attempt to send that data over an insecure or improperly-secured channel. Alas, it's hard to know from just inspection whether data is private or not; just as there's no such thing as an EVIL bit, there's also no PRIVATE bit. (Maybe a pervasive metadata system could do it… Yeah, right. Forget it.) So they just do the best they can and flag up situations where it is extremely likely that there's a problem.
Why do they make it look like such a big deal? Isn't having SSL even if untrusted better than not having it at all?
What threat model are you dealing with?
Browser makers have focused on the case where anyone can synthesize an SSL certificate (because that's indeed the case) and DNS hacks are all too common; what the combination of these means is that you can't know that the IP address you've got for a host name corresponds to the legitimate owner of that domain, and anyone can claim to own that domain. Ah, but you instead trust a CA to at least check that they're issuing the certificate to the right person and that in turn is enough (plus a few other things) to make it possible to work out whether you're talking to the legitimate owner of the domain; it provides a basis for all the rest of the trust involved in a secure conversation. Hopefully the bank will have used other unblockable communications (e.g., a letter sent by post) to tell people to check that the identity of the site is right (EV certs help a little here) but that's still a bit of a band-aid given how unsuspicious some users are.
The problems with this come from CAs who don't apply proper checks (frankly, they ought to be kicked off the gravy train for failing their duty) and users who'll tell anyone anything. You can't stop them from deliberately posting their own CC# on a public message board run by some shady characters from Smolensk[1], no matter how stupid an idea that is…
[1] Not that there's anything wrong with that city. The point would be the same if you substituted with Tallahassee, Ballarat, Lagos, Chonqing, Bogota, Salerno, Durban, Mumbai, … There are scum all over.
Application I am developing does some kind of server-side authorization. Communication is done via secure channel (HTTPS in my case, with valid SSL cert). I plan to implement something that will verify if remote server is exactly who he claims to be.
I know that no client-side protection is unbreakable, especially given enough time and knowledge. But, if I implement what I described above, is this security approach "secure enough" to protect data from being tampered with, while in transit, or to prevent man-in-the-middle attacks, and to ensure its validity?
I am considering adding another layer of security around transfered data (by using private/public key pair), but I suspect it might be enough to rely on SSL, without reinventing the wheel.
SSL is secure enough with a valid certificate, but ...
A lot of people don't know that getting an invalid certificate error is something that means "Your data is possibly going to be intercept by someone else". They will just ignore the warning and Man-in-the-middle-attack will still work. Also, some older browser like IE6 might not even show you any warning if the certificate is invalid. The problem in this case would be the user, not the technology used. This means that instead of trying to build an other layer of security you should teach the people who use your application what does it means to get an invalid certificate error and why they should use a modern browser.
Mr. B,
As you mentioned that client is going to validate the server SSL certificate and that users are not part of process, I think you will be just fine validating the server SSL certificate. However, you must take good care of verification process. I've seen several client applications which doesn't verify the certificate well enough. By "well enough" I mean that client should verify - 1) Certifying authority 2) Duration 3) Site issued to
One of the app I was pen testing had the bug that it was verifying the "CN" of certificate - which can be spoofed (one could create a bogus certificate with arbitrary CN).