I have a proxy server and I am making an application for the internet. I have no idea, the username and password exchange in between proxy server and client can be encrypted or not? If yes what encryption squid uses? I am curious to send my username and password using encryption. I have done with base64 authorization string.
Well, for a corporate environment it's great to use Kerberos or NTLM authorization type to implement a secured authorization process. This is first option (more details here: https://serverfault.com/questions/106846/squid-authentication-encryption).
The second option is to use HTTPS_PORT directive in Squid, so your clients will be able to establish a fully encrypted SSL-connection to the proxy-server (http://wiki.squid-cache.org/Features/HTTPS#Encrypted_browser-Squid_connection — not just authorization, so since this moment you can use even plain-auth one).
To implement this Squid should be compiled with --enable_ssl flag, server should have a FQDN and attached to that domain name certificate.
Example:
https_port 3143 cert=/etc/squid3/ssl/cert.pem key=/etc/squid3/ssl/private.key
Note, that certificate should be exactly in PEM format and private key shouldn't be locked with password. You may get a free and legit one from StartSSL, to example. Or you may use a self-signed one, but it's not a great idea.
There are few limitations:
1) HTTPS-proxy (do not confuse it with proxy, which simply supports CONNECT method) is well supported only by Firefox and Chrome at this time.
2) It works only in cooperation with proxy auto-configuration (PAC) file, more details here: http://www.chromium.org/developers/design-documents/secure-web-proxy
Related
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.
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.
I have some dedicated servers running ASP.NET applications over internet. All servers are fully trusted (all belongs to the same company) and need to communicate to each other in a secure way. They are not part of a domain or work group and should not be.
Each server acts as both client and server of some WCF services. These services are few (1-2 per server) and light (a little data is transferred on each call).
I can use self-signed SSL certificates or X509. I'm looking for some way to make sure nobody from internet can call a WCF service on a server. New server would be added in the future.
I read about WCF but now I'm confused, is it good idea to use self-signed SSL certificates or not (non self-signed is not an option at the moment), which binding to use, which security mode to use, which authentication method to use...
I need some hints to start (please provide a link to a sample.
I would use a certificate-based authentication where both client and server are authenticated.
To make things more secure, do not use self sign certificates.
If your company already have a certificate server: issue certificates to each of your server and specify as an authentication configuration that both client and services need to present a certificate issued by your certificate server.
WCF security is a big topic, but there are some other non-WCF specific ways you can secure the service:
Use IP SEC to secure the communication channel
Use IP whitelists to grant / deny access to the port that the WCF endpoints operate on
Use a VPN Solution (particularly convenient if your company already has a site to site VPN)
Apart from enhanced authentication options offered by SSH, is there any difference between basic working of SSH and SSL protocols ?
I am asking since we can use SFTP or FTP over SSL, both would require authentication.
What is the difference between SSH and SSL and why would we care?
SSL stands for "Secure Sockets Layer". We care because it enables browsers to transmit data to and from a web server in a secure cryptographic way to make life hard for third party spies monitoring all internet traffic.
SSH stands for "Secure Shell". We care because it enables a networked computer 1 to provide access to a shell on networked computer 2. The user can have a level of confidence that spies listening to the insecure channel cannot decrypt data sent between the networked computers.
SSL and SSH both have to do with providing a system to encrypt and decrypt data over an insecure channel.
When a browser visits a URL which begins with "https://", the browser speaks HTTP over an SSL connection.
SSL enabled Web Servers (for example Apache HTTP Server) can be configured to use SSL to become a "secure web server". A website served up by a secure web server will cause users to access the URL through the "https://" protocol instead of "http://". With the https protocol the users can have a level of confidence that third party spies monitoring the internet channel will only receive encrypted content.
SSL is a Protocol that could be implemented in the 6th layer (Presentation layer) of the OSI Model.
SSH has its own transport protocol independent from SSL, so that means SSH DOES NOT use SSL under the hood.
Cryptographically, both Secure Shell and Secure sockets Layer are equally secure.
An SSL Termination Proxy can handle incoming SSL connections, decrypting the SSL and passing on the unencrypted request to other servers.
SSL lets you use a PKI (public-key infrastructure) via signed certificates. With SSH you have to exchange the key fingerprints manually through another protocol like ftp or carrier pigeon.
The main difference is that SSL lets you use a PKI (via signed certificates). In SSH you have to exchange the key fingerprints out-of-band. But you might want to do without a PKI anyway, in which case it's a tie.
For a nice explanation, see http://www.snailbook.com/faq/ssl.auto.html
SSH and SSL are similar protocols that both use most of the same cryptographic primitives under the hood, so they are both as secure as each other. One advantage of SSH is that using key-pair authentication is actually quite easy to do, and built right into the protocol.
With SSL it's a bit of a mess involving CA certificates and other things. After you have the PKI in place you also need to configure your services to use the PKI for authentication instead of its internal password database; this is a nightmare on some services and a piece of cake on others. It also means you need to go to the hassle of signing all of your user's keys so they can log in with them.
Most competent users can grok SSH keys in no time but it takes a bit longer to get their heads around SSL keys (the extra CA certs and key certs confused me when I first discovered it).
Pick what's supportable. SSH+SFTP is great for Unix people, but FTP over SSL is probably easier to do if your users are Windows-based and are pretty clueless about anything other than Internet Exploiter (and you don't mind risking that your users will choose insecure passwords).
Cryptographically they are both equally secure (given that same ciphers are used). Other than that they are entirely different protocols...
First of all, TLS server authentication is optional since its protocol supports fully anonymous server authentication. In SSH this is mandatory.
TLS uses X.509 certificates for client and server authentication, which would require some sort of PKI. SSH does not scale in this point but offers a wider range of authentication methods: password, public key, etc.
Another difference is that SSH allows multiple connections and supports remote program execution, terminal management, TCP tunneling and so on.