I am developing browser extension, that sends some data from currently browsed page to my backend server. User is aware of it, it is intended.
I don't want to cause any user-data exposure, when the user is e.g. on unsecured wifi. So I just want to ensure, the data and the url goes over the net encrypted and only my backend will see them.
Do I understand correctly, that any SSL certificate, even free one from StartSSL will do the trick?
What other side effects with free SSL certificate should I consider?
- will the user's http-client trust such a certificate?
Thanks.
The SSL certificate will do the trick as long as it can be validated. That means that the root certificate of the certificate chain needs to be within the trusted certificate store of the browser.
Furthermore, the certificate will have to be for the right address (URL), must not be revoked, CRL's and OCSP must be configured correctly etc. etc. In other words, the usual steps required to have your web-service certificate validated must be met.
Related
I'm building a PHP web app that uses AWS RDS. In order to make the connection encrypted, I need to download the SSL certificate from RDS and store it on the app server so that the app can use it. But I remember when I use SQL workbench it somehow knows how to connect with SSL to the RDS instance without me downloading the certificate and telling it where the certificate is stored. Also after reviewing the way how HTTPS works, I know that the client doesn't need to store a certificate the first time it connects to a server, it download the certificate itself. So my question is for my app to connect to RNS instance using SSL, why do I need to first download the cert and tell my app where it's stored? Shouldn't my app know how to get the certificate itself?
Certificate validation requires a trusted root CA. Trusted means that the CA is in the local trust store. Depending on what site you connect to and what certificate you get it might be a certificate issued by a CA you already trust or not. In the latter case you would need to explicitly get the so far untrusted CA certificate first and somehow treat it as trusted.
The need to explicitly import a CA as trusted is typically true for self-signed certificates which is usually considered bad practice but depending on the specific environment might make sense. It can also happen for company specific CA but these should better by rolled out to the various systems by an automated process. It might also happen when a misconfigured server does not send a required intermediate certificate, in which case it would be better to fix this server.
Note that you should not import arbitrary CA certificates and consider these trusted. Whoever owns this CA can issue arbitrary certificates even for existing domains like google.com and your application will then blindly trust these faked certificates too, making man in the middle attacks possible.
I have installed a SSL certificate (comodo PositiveSSL) for my domain and forced NGINX to only use HTTPS.
I run the test on SSL analyzer
https://sslanalyzer.comodoca.com/?url=domain.com
Validation Type Domain Validated (DV)
Trusted by Microsoft? Yes
Trusted by Mozilla? Yes
We have our mobile app for Android and IOS getting some data from our https://example.com/api webservices.
So i have installed Packet Capture mobile app on my android to verify whether the data transferred between the webservice api and our mobile app is secured.
First i tried with enabling the following in Packet capture mobile app :-
I have contacted comodo ssl support, they said
that the certificate is installed well and its working fine. There is
nothing wrong with the certificate and installation process and the
web-site https://example.com/ is also completely secured with Green Pad
lock on it.
I run the same test on instagram app, when open instagram , showing network error. Like instagram discovering by some way that i am trying to capture a network packets so their app network will be disabled.
I want to do the same way of what instagram did .
Please Advice.
Don't worry, if your certificate is valid and contains the right domain name then you've already done everything needed.
A "man in the middle attack" is an attack done on the client.
The client think the attacker is the website by compromising his DNS
Then the attacker relay in and out traffic from/to the real server.
The server is secure but not the client.
Like RamKumar said the client need to trust the attacker certificate like you did
EDIT:
You can also use TLS with mutual authentication (mTLS).
With this protocol the client AND the server exchange certificate public keys.
It work as follow:
A client requests access to a protected resource.
The server presents its certificate to the client.
The client verifies the server’s certificate.
If successful, the client sends its certificate to the server.
The server verifies the client’s credentials.
If successful, the server grants access to the protected resource requested by the client.
Some sample:
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/october/mutual-authentication-in-android-and-ios/
With this protocol the man in the middle attack is still possible but the attacker's certificates need to be trusted by both client and server
Another custom approach would be to add another layer of encryption using asymetric cipher.
To remove that possibility you can use Certificate Pinning to make sure that only the specific Certificate you use can be used to prevent the device from using any other Certificate, even if it was signed from a trusted CA. This may still be circumvented by a user, but now he has to modify the application itself in order to disable the check, or change the pinned certificate
Have a look at how Certificate Authority (CA) works. In your case, what happens is that the Packet capture mobile app installs it's own CA. Now Packet capture becomes a trusted CA for your device and certificates signed by them are accepted. Then this app creates its own certificate saying example.com and signs it.
So when it performs man in the middle attack, the client (your app) communicates with Packet capture and not example.com, but your app believes it's communicating with the example.com, since the certificate provided by Packet capture is signed by a trusted CA (Packet capture CA itself).
Hence this works only when your install their CA. However a secured connection is made between Packet capture and example.com
I have a portofolio website runing on a IIS Windows server if that matters.But some people complained that they get "website unsafe" when navigating the website.I personaly didnt get that error , and I tried the website on other diveces and they didnt get it either.
Could have something to do with SSL Certificate ? I didn't bought one ,but I have a self signed certificate according to ssl checker
.Do I need to buy a trusted SSL Certificate ? Or is there another problem ?
On my website i have a "Contact us" page with a web form that users should fill with name,email...
EDIT: I don't know if it's ok to post the website link here, if it's needed let me know .
EDIT: Link to website here.
This is a general problem with self-signed certificates, as the visitors of you website, or their browser, are not able to verify the identity of your server. The reason for this is, that there is no Certification Authority that signed it, thus the browser does not have a (root) certificate that is in the chain of trust linked to your certificate.
This problem with self-signed certificates is well explained in this post
The risks are for the client. The point of the SSL server certificate is that it is used by the client to know the server public key, with some level of guarantee that the key indeed belongs to the intended server. The guarantee comes from the CA: the CA is supposed to perform extensive verification of the requester identity before issuing the certificate.
When a client (the user and his Web browser) "accepts" a certificate which has not been issued by one of the CA that the client trusts (the CA which were embedded in Windows by Microsoft), then the risk is that the client is currently talking to a fake server, i.e. is under attack. Note that passive attacks (the attacker observes the data but does not alter it in any way) are thwarted by SSL regardless of whether the CA certificate was issued by a mainstream CA or not.
On a general basis, you do not want to train your users to ignore the scary security warning from the browser, because this makes them vulnerable to such server impersonation attacks (which are not that hard to mount, e.g. with DNS poisoning). On the other hand, if you can confirm, through some other way, that the certificate is genuine that one time, then the browser will remember the certificate and will not show warnings for subsequent visits as long as the same self-signed certificate is used. The newly proposed Convergence PKI is an extension of this principle. Note that this "remembered certificate" holds as long as the certificate is unchanged, so you really want to set the expiry date of your self-signed certificate in the far future (but not beyond 2038 if you want to avoid interoperability issues).
It shall be noted that since a self-signed certificate is not "managed" by a CA, there is no possible revocation. If an attacker steals your private key, you permanently lose, whereas CA-issued certificates still have the theoretical safety net of revocation (a way for the CA to declare that a given certificate is rotten). In practice, current Web browser do not check revocation status anyway.
I have a simple question (maybe stupid) and i didn't find any clear answer to it. If i get a certificate from a trusted signing company (like verisign...) for one of my server (web for instance), i'll have private an public keys. With this certificate can i set up my own intermediate CA and sign cert request and the be trusted by every one (i know that's shouldn't be..)? My real question is : what will prevent me for issuing certificate and how the company can garanty that nobody does ??
Thanking in advance!
The certificate issued for your web site is suitable for SSL/TLS and is not suitable for issuing other certificates (Key Usage field is different). Consequently while you technically can generate another certificate using yours as a CA, such generated certificate won't be trusted by properly implemented and configured validators (those that check Key Usage).
You are not paying verisign or other certificate organisation for the certificate publishing but for the certificate validation, this meens that they have web services that respond if your certificate is valid or not, if it is still active and not expired and your contact information as requested.
Unfortunatly this is something you have to live with it and pay them if you really need ssl over your site.
I have used a homemade certificate for my lan server and when i visit this https site a big red warning notifies me that this site is malicious and it has not a valid certificate. This doesn't bother me but I am sure that all of my clients would have freeked out if they see such a bold warning popping up to their browser.
what can you do? it's a companies' world
I need to implement a SSL certificate for a website, I've got three questions after some research.
1) I believe i need to buy a SSL certificate and ask my host to install it. My question is do you need to alter any code for the website for the certificate?
2) Before I buy the certificate, the website is going to be built for a couple of month at least. I'm just wondering is there a developing SSL certificate I can use for the developing environment?
3) Or do I have to use self assigned certificate? If so are there any good tutorials on how to create a SSL self assigned certificate on a local machine (wamp) and a developing url site?
Thank you very much.
Sam :)
1) No, you do not need to alter any code on your website at all in order to use an installed SSL certificate. It is as simple as prefixing your desired destination link with the HTTPS: protocol specification instead of the typical HTTP: protocol. However, if you want to determine if your site visitor is using an encrypted page before they do something, such as submit a web form with potentially sensitive data, then depending on what you are developing your site in, you will need to detect if the current page request has been sent over HTTP or HTTPS, then if it is an HTTP requested page, you probably want to redirect the page request to the HTTPS version before proceeding.
2) Other than creating your own "self signed" certificate (more on this in #3), no your only option for a publicly valid SSL certificate is to obtain one from a publicly recognized Certificate Authority (CA). Long story short, a certificate of the same key length using the same encryption standard supported by your server and visitor's web browser, is no stronger or weaker regardless of vendor for purposes of encryption. So you can simply shop by price for your SSL certs. I have no affiliation with GoDaddy, but have been using them for years for public SSL certificates.
3) You certainly can create your own self signed certificate. The methods for doing this vary based on your host server and version. The limitation to a self signed certificate, is that if you go to share this with anyone, you get that warning message from your browser that the certificate is not published from a verifiable source. In most current browsers, it looks like a big scary message that something is wrong and they attempt to warn your user away from doing this. However, of course, there is certainly nothing wrong with using a self signed certificate. This is obviously true for your own development uses. Even a self signed certificate of the same key length and encryption method is as cryptographically secure as a commercially provided certificate. If you want to use a self signed certificate, just search for instruction for doing that for your server OS and version for details. Once it is installed, you will get the warning from your browser when you try to browse to a page over HTTPS. Your browser should show you an option to permanently remember and accept your self signed certificate, after which you will no longer see that warning while that certificate remains installed and valid.