I have a requirement in my project where I have to secure the communication between my client application (running on BizTalk Server Send port configured with Office 365 Email adaptor) and Microsoft Office 365 Server. This communication is to be secured by TLS 1.2 and a certificate is provided by MS O365 server during Server hello (handshake process) to later securely exchange the symmetric key generated at client side.
Do I need to install another certificate at client side for either generating this symmetric key or for any other purpose to achieve a better secured communication between the client and server?
No, you don't require another certificates client side (BizTalk) to establish a TLS 1.2 connection.
The BizTalk Server needs to trust the certificate however, but as this is one issues by Microsoft, it should be trusted.
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
My understanding is that SSL combines an encryption algorithm (like AES, DES, etc.) with a key exchange method (like Diffie-Hellman) to provide secure encryption and identification services between two endpoints on an un-secure network (like the Internet).
My understanding is that SASL is an MD5/Kerberos protocol that pretty much does the same thing.
So my question: what are the pros/cons to choosing both and what scenarios make either more preferable? Basically, I'm looking for some guidelines to follow when choosing SSL or to go with SASL instead.
It's quite difficult to compare SSL/TLS and SASL, because SSL/TLS is a communication protocol, whereas SASL is a framework, integrated with other protocols. (In fact, you can use both at the same time in some circumstances.)
In addition, you're mentioning Kerberos, which is indeed an authentication protocol (which can be used with SSL/TLS or SASL or independently both). Your question seems to suggest that whether or not to use Kerberos one of the main sub-problems you should choose first.
SASL is essentially an indirection layer to allow for pluggable authentication systems and data security in existing application protocols (e.g LDAP, SMTP, Subversion, ...), although these protocols need to be aware of this extension (e.g. SMTP auth). Whether and how it provides secure authentication and data encryption depend heavily on what underlying mechanism is used within this framework. Here is an example from the svnserve documentation: "The built-in CRAM-MD5 mechanism doesn't support encryption, but DIGEST-MD5 does".
If you want to use Kerberos with SASL, you will need another level of indirection: GSS-API (which is most commonly used with Kerberos, but can also allow for other mechanisms). (Note that GSSAPI in the context of SASL seems to imply Kerberos anyway, unlike its GS2 successor.)
The general goal of SSL/TLS is to secure the communication (integrity and confidentiality) between a client and a server. The client should always check the identity of the SSL/TLS server, and it provides mechanisms for server to check the identity of the client too. What it can do also depends on how it is configured. SSL/TLS is most commonly used with X.509 certificates: that's how a browser can check the identity of an HTTPS server. Servers can also be configured to request the client to use a certificate to identify themselves (client-certificate authentication).
However, if you want to use Kerberos, you can use TLS Kerberos cipher suites. This is much less common, but they are implemented in the JSSE.
Its implementations usually provide APIs similar to what you get with plain TCP connections: in Java, once configured, you can more or less use an SSLSocket as you would use a plain Socket. This doesn't require specific awareness by the protocol on top of the socket, although some protocols have explicit commands to switch to SSL/TLS from a plain connection (Implicit v.s. Explicit SSL/TLS). It can also provide authentication. In Java, the JSSE is the default SSL/TLS implementation, which gives you access to SSLSocket (or SSLEngine if you're brave enough).
You might want to read "When to use Java GSS-API vs. JSSE", which is similar to "SASL vs. SSL/TLS" (although it doesn't seem to have been updated for a while, since the JSSE does support Kerberos cipher suites now, at least since Oracle Java 6).
I'll admit I know less about SASL than about SSL/TLS, but doing data encryption via SASL sounds like it's going to be more work. It doesn't seem to have certain SSL/TLS features such as the Perfect Forward Secrecy offered by EDH cipher suites. There is an example that uses SASL with GSSAPI (Kerberos here) in the JGSS tutorial: you need to wrap/unwrap the data explicitly, which you wouldn't have to do when using SSLSockets.
I think your main concern should be to decide which authentication mechanism you want to use in the first place: Kerberos, X.509 certificates, or something else. This will have more impact on your overall architecture, and both can be used with SASL and SSL/TLS (more so if you use SASL with an EXTERNAL mechanism, when on top of an SSL/TLS connection).
Kerberos is very centralised. The client will need to be able to contact the KDC to authenticate, in addition to being able to contact your application server. The clients will also need to be configured to use that KDC. From a user's point of view, they can use passwords.
X.509 is more decentralised. However, you may need to deploy a Certification Authority (or use a commercial one) for your user certificates. Users will need to be given certificates and private keys, which some might find too complex.
JAAS comes into it because it's the general Java framework for dealing with authentication and authorisation. It's very closely linked to the notion of security managers. It gives you the notion of Subject and Principal. This isn't directly linked to the protocols or the communication, but rather to the way you model authentication and authorisation within your application. (It gives you a standard set of classes to do so.)
(I'd generally suggest to go through the Java reference documents that mention the words you're after: JGSS, SASL, ..., although they're not necessarily easy to read.)
SSL vs SASL
It's true that SASL is not a protocol but an abstraction layer. It's also true that SSL and SASL are kind of providing similar features. Both of them provide authentication, data signing and encryption.
SSL is done at the transport layer and it is normally transparent to the underneath protocol. For example, you can use SSL on LDAP or HTTP. However, in some cases, modification to existing protocols is necessary in order to switch to secured mode. For example, POP3 and IMAP is extended to have a command STARTTLS to initiate the use of SSL. From that angle, this is kind of similar to what SASL doing.
On the other side, many protocols are also extended to provide SASL capability. Here is the list of protocols. Again, POP3 and IMAP are two of them and they are using different commands to initiate the authentication.
So, when should we use SSL and when should we use SASL?
An obvious difference between SSL and SASL is that SASL allows you to select different mechanisms to authenticate the client while SSL is kind of binded to do authentication based on certificate. In SASL, you can choose to use GSSAPI, Kerberos, NTLM, etc.
Because of this difference, there are some situations, it's just more intuitive to use SASL but not SSL. For example, your client application is using Kerberos to authenticate the end user. Your server needs to authenticates the client. Since your client application already have a Kerberos credentials (in Kerberos terminology, a ticket), it makes sense to use the Kerberos credentials to authenticate with the server. Of course, you can always setup SSL to do the same thing. However, that means on top of the existing Kerberos infrastructure, you need to setup Certificate Authority infrasture and somehow correlate the client certificate with the Kerberos credentials. It's doable but a lot of work.
Also, sometimes, you need to use some features that available only in the SASL mechanism but not the SSL. For example, Kerberos allows you to forward the ticket from the client to the server so that the server can use the ticket to query some resources on behalf of the client. One common example is that you have a application server and a database. The client application authenticates with the application server and the application server needs to query the database on behalf of the client using client's credentials. SSL cannot provide this feature to you but Kerberos supports this. So, in that case, you have to choose to use SASL.
In some cases, you do want to use SSL but not SASL. For example, extending the protocol is not an option or you want to encrypt every single packet exchanged using underneath protocol.
How does GSSAPI relate to Kerberos and SASL
According to this wiki page, both GSSAPI and Kerberos are supported mechansim in SASL. GSSAPI is a generic programming interface. The idea is to let application writer use one single common API to do authentication, encryption, etc regardless of what protocol is used underneath. GSSAPI implements Kerberos. So, you can use GSSAPI to do Kerberos authentication.
How does JAAS relate to SASL
To be honest, I am not a Java expert. From what I read, it sounds like JAAS is just a pluggable authentication framework. I beleive the idea is similar to GSSAPI. It's to provide a single programming interface regardless of what authentication method is using. While GSSAPI is focusing on authentication and secured message exchange, JAAS is focusing on authentication and authorization. I don't find any evidence that JAAS is also one of the SASL mechanism. I believe there should be some helper classes from Java library helping you to implement custom SASL mechanisms. While implementing the custom SASL mechanism, it may makes sense to just use JAAS.
SASL is not a protocol but an abstraction layer to some auth mechanism. If you use Digest-MD5 or GSS-API as your SASL mechanism you can request SASL to completely encrypt your data traffic. This is for example what I do to talk to your Active Directory servers. You won't need SSL. What is your use case? Please elaborate!
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.