Basically, I'm using a remote object that access to a secure EndPoint. This
EndPoint is located into my server. It means that my channel is a
SecureAMFChannel. If I accept the certificat by going directly to this URL with
my browser, then I'm able to run my flex application and to exchange some data.
However, if I'dont go to this url to accept the server's certificat, and launch
my Flex application, the remoteObject is not able to accept the certificat. And
of course, any information can be exchanged.
My problem is, how to accept automatically a certificat in a Flex application.
Do I need to configure something to accept it? Maybe my manipulation is not
correct.
My certificat is self-signed, do you think that this problem could be solved by buying a Certificat signed by a CA?
Could you tell how to solve this?
Thank you very much,
Bat
You can't accept a self-signed certificate in Flex. The Flash Player trusts only those CAs that are trusted by the browser.
So, either add your own CA which you used to sign your certificate to the trusted CAs of your browser or buy a certificate from a well known CA. I'd strongly advise you to do the latter since using self-signed certificates is more or less as insecure as using no SSL/TLS at all.
Related
We have equipment which have public IP addresses and we don't have SSH access to it. In order to secure their login screens, we need to use the HTTPS, but when we do that it is always complaining about insecure connection due to wrong SSL certificate. I am aware that we cannot issue SSL cert on an IP, but the other problem is that we don't have access to the equipment either in order to install a new SSL certificate. So what are the security recommendations in this case. Is the traffic still secure and encrypted in case of SSL mismatch.
I know that we can limit the networks who have access to this IP, but are there any other security measures?
Your main problem here is an active attacker. When you connect via HTTPS, the server will send its certificate, claiming to be the web server where you're trying to connect (let's call it "SecureServer"), and the Certificate Authority (CA) will be the one in charge of letting you know if "SecureServer" really is who it claims to be. When using a self-signed certificate or something like that, there'll be a warning letting you know that it's not a secure connection, because there's no way to verify that "SecureServer" is really who it claims to be, after all, you're not a CA, and because of that, you can even create certificates for "google.com", but since you aren't an authority, nobody's going to trust you.
Now, the problem here is that if someone wants to connect to your device, they'll see that warning and they'll be like "oh yeah, that happens all the time. Just skip it and keep working", but an active attacker can intercept that communication, add his own certificate, instead of the server certificate and voilá, now he'll have access to your encrypted communication, because now the communication is between you and the attacker, and if you're waiting for a response from the server, he can also establish a communication with the server, so he'll forward all your requests to the server, while reading all your requests and server responses. All this is possible because once the active attacker has intercepted the communication, you'll see that warning, but all your users are used to just ignoring that warning, and they'll just accept the communication anyway, while when using a certificate issued by a CA, if they see that warning, they'll know that there's something wrong.
Honestly, for me, the best thing that you can do here is to use a certificate issued by a CA. Also, according to this answer, you can issue an SSL certificate on an IP address (I've never tried it before, but it might be worth to give it a try). You also mentioned that you don't have access to the hardware to install that certificate, but I'm guessing that you can request that to someone who has access to it, just explain the situation and if he/she is a reasonable person, he/she will understand the problem and will install a new certificate. Because honestly, just limiting the IPs range or something like that, is just a workaround for something that should be implemented correctly.
I am trying to set up smart card authentication for a website that I have created. Setting authentication to Windows and setting SSL to required I can get the smart card reader to pop up when they go to the web site. There are 2 credentials on the card though and only one of them is showing up as an option (the information I need is on the other credential). I asked a co worker and he said in IIS 6 there was a way to specify a location on the smart card to look for certificates. I have been researching this issue for about a week now but haven't been able to find a solution to this issue yet. Does anyone know how to do this?
IIS really only knows about certificate-based authentication, not smart-cards per se (which is really just a form of cert-based authentication). Configure your site to use certificate-based authentication, eg "Require Client Certificates" and IIS will chain the call down to Windows security, which, in turn, recognizes that among the sources for identity certificates is the smartcard reader. Depending upon your site requirements, you may also need to enable Certificate Mapping, which translates certificates into Windows account identities.
When certificates are required (or accepted) IIS will ask for a client cert in the SSL negotiation when the session is started. IIS will send a list of the Certificate Authorities it trusts to the client. The client then takes those and sees which match the list of Certificate Authorities it trusts. It then take sthe list of common entries and checks to see if it has any certs issued by a CA both sides trust. Generally, if there are none it will simply not send a cert and the request fails if the cert is required. If there is just one certificate IE will generally send that without asking the client which cert to send, but it will prompt for a PIN if required. Finally, if there are more than one certificate issued by a CA both sides trust then a dialog box will be presented to the client asking which cert to use.
In this case it sounds like perhaps the credential (certificate) you want the client to send is issued by a Certificate Authority that isn't trusted by one or both sides.
I've a quick question:
I have 2 websites, 1 has some links to file downloads. Those files are hosted on another server.
I need to encrypt the request data between the 2 servers..can I do it just using a SSL certificate?
Any other/better idea?
Those files are private docs, so I don't want the server 2 or any other people being able to track the file requests between the servers.
Thanks
Yes, use SSL (or actually TLS) if you want to achieve transport level security. If these are two servers that you control you can configure your own self signed certificates. If you want to make sure that only the two servers can communicate with each other, then require client-authentication, where both the server and client use a certificate/private key pair.
Most of the time the trick is to implement a sensible key management procedure. Setting up a web server to handle TLS using certificates should not be too hard.
SSL certificate will work fine for ensuring the transfer is encrypted. Even just a self signed certificate will be fine for this purpose (provided you can tell the client you're going to use to accept the self signed cert)
Alternatively if it's two linux machines then scp (secure copy) is a great tool where it'll connect via ssh and grab the files. (There probably is a windows scp tool but I don't know it)
Rsync also supports going via ssh
As for tracking the request... there's nothing you can do to prevent any device between your computer and the destination computer logging the fact a connection was made but the encryption should prevent anyone from getting to the actual data you're sending.
Issues have been asked many times about how to handle self-signed certificates with Java and implementations are often provided. However, I'm not sure that these implementations will give me the security/trust I am looking for.
My circumstance is as follows: I have a client program connecting to our server application. Both of these we have complete control over. Our client post's a stream using https to a URL at our server, and the server responds. Currently (and this is what I'm trying to fix) the server has a self signed certificate. Java doesn't like this and FOR TESTING ONLY, we are pretty much ignoring the certificate altogether by trusting any certificate.
I have little knowledge of SSL. My boss says we can use our self-signed certificate and it will be secure as long we don't make our crypt. key public. This sounds correct to me, but a lot of posts say self-signed cert's are automatically vulnerable to man-in-the-middle attacks. Does this mean SSL sends the crypt. key along with the certificate?
Since we have control over both ends, should we just encrypt our data ourselves with a secret key, and decrypt it at the end using our key? Or is there reason to use SSL?
Instead of trusting any certificate blindly (which would make the connection vulnerable to MITM attacks), configure your Java client to trust that particular certificate. Self-signed certificates do not inherently make SSL/TLS connections vulnerable to MITM attacks, they just make their distribution and the evaluation of trust more specific to this particular deployment (i.e. you have to configure it manually).
You can do this in at least 3 ways (pick the easiest one for you, I'd suggest bullet point #2):
Import the server certificate into your client's global trust store (lib/security/cacerts in your JRE directory). This will make all applications run with this JRE trust this certificate.
Import the server certificate into another truststore (possibly a local copy of lib/security/cacerts) and make this particular application use this truststore. This can be done using the javax.net.ssl.trustStore system properties.
Make your client application use an SSLContext initialised with an X509TrustManager configured to trust that certificate: either something written manually or a trust manager coming from TrustManagerFactory initialised by loading a local keystore that contains that particular certificate (as in the previous method).
You'll find more details about all this in the JSSE Reference Guide.
(This answer to a similar question should give you the details for doing all this properly, in particular keytool -import ....)
The arguments against self signed certificates mainly apply to web-applications. Since with the current infrastructure a browser won't be able to validate your self-signed certificate.
Since you have control over the client, you can simply hardcode the certificate you expect into the client. For example you might calculate the sha1 hash of the certificate, and check if that matches the expected value. That way you don't even need to trust hundreds of CAs.
To achieve secure communication you need to first ensure your talking to the right computer. When the client first attempts to establish a secure connection, it pings the server and the server responds with its cert. At this point you MUST validate the servers cert before continuing. The cert includes a public key and signature that can be used to ensure the cert is valid. For example, in web browsers this means checking to see it's been signed by an authority listed as trusted in your browser settings, if that check fails you'll see red warnings in your browser. In your case this will mean you have manually (or in code) added the servers cert into a trust store so that it is trusted.
How do i check the client browser SSL certificate in my ASP.net code behind
I want to ensure that if any https proxy like fiddler is running then my application does not load
I have done the following till now without any success:
My site is on Https
In IIS i have set
Require SSL= true
Require 128 bit encryption =true
accept certificate = true
in my default.aspx Page_Load i am trying to read the value of Request.ClientCertificate, the collection is coming as empty.
There is no way to do what you're trying to do unless you run an ActiveX control on the client.
Internet Explorer and other browsers do not expose the server's SSL certificate information to the JavaScript in the page, meaning that there's no way for your page, running on the client, to know whether or not it was delivered with your certificate or another certificate.
Having said that, even if such a method was offered, it probably wouldn't help you anyway. Presumably, you want to do this to prevent viewing/modification of your traffic, but there are other tools that plug into the browser directly (post HTTPS-decryption, pre HTTPS-encryption) that can view/modify traffic without resigning it as Fiddler and other proxies do.
Furthermore, your code would fail in corporate environments where the edge proxy (e.g. BlueCoat, Forefront) does content-inspection using the same mechanisms that Fiddler uses.
Are you expecting the client to have a certificate installed? Most users do not have client certificates installed.
Nonetheless, I'm not sure how exactly a client certificate is going to protect you in the situation you describe...