I have a system protected by SSL - and clients use a smartcard for accessing their certificate. I use java's pkcs11.
I have posted this question here (even with bounty):
pkcs11 sso (using prior windows login with smartcard)
The same smartcard is used for windows login - and I would like to save the client the touble of re-logging using the smartcard (PIN).
Many links I have read about this issue led me to the world of SSO: NTLM, Kerberose etc.
I feel SSO is a bit an overspec for what I wanted to acheive - And also by the looks of it - At least kerberose requires me to create a KDC server and other new components that will elongate my development time.
So - some introductory questions about SSO I couldn't find an answer to:
Will it actully solve the problem I presented? (The smartcards contain "classic" certificates signed by CA).
I would like a minimal solution (in terms of components) - which is the best implemnation for this? NTLM, Kerberose? I will probably have to use a jna wrapper like WAFFLE, right? By the way, I will use WINDOWS as OS.
Thank you for your help.
The only way is to set up a Windows Active Directory (a KDC impl) to use the full power of SSO with Kerberos. There is no other option. Don't use NTLM, it has a lot of drawbacks. Waffle has its drawbacks. Due its different nature, it does not integrate into JGSS and makes it unusable comprehensively in Java.
If you want to avoid licensing fees for Windows server, you may try Samba 4 which is an OSS alternative to the AD.
I am doing this for years in a corporate environment from Windows client to a Unix-based server.
Related
I have a java applet on a website (http://martinogames.x10.mx/) but it gets blocked by java security settings. It is a signed applet created using the AppletMaker tool in processing. I know how to allow access on my computer (java security settings to medium/whitelist the site), but I want to know how to get Java to accept it for other users. I am the developer and should have access to all information needed to do this, if it is possible.
Thanks in advance,
-Peperononew
You need to buy a real certificate and sign it with that. Otherwise it would require users to trust your certificate, which is not secure at all (you're not a trustworthy entity).
I am writing a Java proxy which communicates to other servers using SSL.
It all works well using ServerSocketFactory along with keystore and trustore which is populated with the server cert.
I wonder, is there a way in Java 7 to disable the certification and trust all servers? (and yes I know this is risky - bu the proxy is for internal use only)
I have seen some examples of implementing TrustManager using X509TrustManager implementation, although apparently Java 7 does not support these contracts and X509TrustManager itself has been deprecated.
Appreciate your advise and any code sample on Java 7 that works.
MITM proxy servers (i.e. servers capable of looking into SSL/TLS traffic) normally use their own CA to generate fake certificates for the requested site.
Install this CA certificate in your client's trust store instead of tweaking the code. This is a much cleaner solution, and in the long run, it's easier to deploy.
(For a more direct answer to your question, the countless example of trust managers that do nothing still work fine in Java 7.)
What I did was implementing a java.security.Provider using the code mentioned in this post
https://code.google.com/p/misc-utils/wiki/JavaHttpsUrl
Note: it is the second solution offered.
This post does not mention that you should also add a keystore in-order to make things work.
So, these VM argument should be set as well (Unless so you will get an error message of "no cipher suites in common"):
-Djavax.net.ssl.keyStore=KEYSTORE LOCATION
-Djavax.net.ssl.keyStorePassword=YOUR PASS
I hope this will help you, since in all the places I looked at this part was not mentioned.
I'm currently investigating for a client a solution where he wants to send and receive files using sftp in Domino.
I have looked on the net for API's covering this and found one recommended more than others; JSch.
One reason for choosing this API is for its use by others including Eclipse.
What I'd like to know is:
if there're any obsticales using this Library? If so, can you recommend any other?
are there any other caveats using sftp in Domino Java?
does Domino JVM support JavaTM Cryptography Extension (JCE)?
can we use Dominos self-signed certificates here, with Dominos CA?
/Mike
1) Sending. This should work, but you will probably have to deal with the JVM's Security Manager ("/jvm/lib/security/java.policy") of Domino to get a socket, ...
2) Receiving: You probably don't want to implement a SSH server inside domino. It's much easier and more secure to use the SSH server of the host and periodicaly scoop up the inbound files via an Agent.
Dominos Self Signed SSL certificates have nothing to do with SSH as implemented by JSch.
3) The Domino JVm will probably support theJavaTM Cryptography Extension (JCE). Watch out for the supported JRE versions of Domino.
4) Generally: Are you sure, you want to implement it that way? Probably way easier are either WebServices or a REST-API, both via SSL/TLS and optionally facilitating client certificates.
I'm in the "pre-design" phase (if there is such a thing!) for a Java EE app that will use a Swing box on the client end and implement components for both web and server tiers.
I'm instantly presented with some technology choices and have been reading up on the differences between how Kerberos and SSL work. One area that I have not been able to find any answers to has been the subject of how to choose between Kerberos or SSL. In other words, how do you tell when it is appropriate to use either protocol?
Let's assume that the Swing client isn't bound by a particular transport (UDP, TCP or otherwise) and could use either/any. How does one choose between which of these two is a better match for their application?
Thanks!
and suddenly (several months later) a wild Sys Admin appears...
I'm going to have to be a voice of dissent on this. The notion that you would ever establish a PKI without a CA is incredibly absurd. You have to maintain the integrity and performance of the PKI by streamlining the creation process. You have to create and store the certs somewhere, where is that going to be? Boom, you have a CA. Any decent PKI is also going to require a CRL be maintained, is the administrator supposed to just write that by hand? You can also forget about having different types of 509's as the overhead of maintaining that by hand would blow-your-mind-wide-open-and-turn-it-into-grey-slurry.
I suppose you could just manually create the tickets with openssl's CLI and just ftp them to the remote clients, but that gets to be a HUGE hassle for deployments of appreciable size. Essentially, if your deployment is so small that generating the certs by hand (repetitive entering of information and all) and then just not worrying about a CRL is a reasonable plan, you don't need an advanced authentication system at all. Something along the lines of TLS+LDAP (one server cert for confidentiality and not authentication) is more appropriate.
Ok, now that I've cleared some misconceptions, let's actually answer your question: When would you want to use SSL over Kerberos for authentication? x509-based authentication is an incredibly nebulous beast, mostly on account that most people (like Michael-O above) don't realize that SSL work specifically because it's authenticating users. There are a few FTP programs that I know of that authenticate that way, middleware employs it...sometimes (which sounds close to your use case from the java talk), and vpn clients/gateways often authenticate with SSL certs.
Usage of SSL would imply the PKI I spoke of up there, which would work great if your use case involves confidentiality. DoD is a good example of an enterprise that makes extensive use of PKI for functions outside of authentication. In that context, supposing all relevant client programs support x509 authentication makes a lot of sense. It's still an exotic set up, and you would still have to figure out how the end-users will "present" their SSL credentials to the system (client configuration, smart cards, etc) but it would fit together nicely. Besides the odd fit, kerberos authenticates by way of a temporary ticket, whereas SSL certs typically last a long time (which is why a CRL is required) meaning that if the never-changing key is factored on one cert the attacker will have several months of free rides before they have to find a new cert, versus kerberos where they only have it for a day and that's only if the ticket isn't destroyed.
All other cases should use Kerberos authentication when possible. It provides the right layer of security and is actually designed as a large network authentication system, which is why you have things that are hard to duplicate with SSL (like authenticating as a service instead of a regular user) and just plain work for their intended purpose. Your use cases are always going to need to take into account existing infrastructure which is probably going to be kerberos-oriented, sometimes LDAPS-oriented, but almost never x509 authentication-oriented. In other words: whatever you're writing is MUCH more likely to be running in a kerberos infrastructure already, so you might as well plug into that somehow. You'll also benefit more from administrator familiarity with Kerberos-as-authentication than 509-as-authentication. The con on this is that confidentiality outside of the ticket is kind of a joke. NFSv4 has some weak DES (and no I didn't mean 3DES even) encryption that it (somehow) relates to the kerberos ticket but it does authentication and that's basically all it does.
I'd like to see some of x509's flexibility combined with kerberos-style infrastructure (recognition of services and the "one time pad" aspect of having a soon-to-expire ticket) incorporated into a solution that was more widely implemented than x509 is now, but at this stage it's mostly day-dreaming.
Summary:
x509 is good if infrastructure requirements won't be a problem and you'll be using PKI for other stuff anyways, but might be duplicating effort needlessly otherwise or if the deployment is probably going to have a kerberos infrastructure anyways.
Kerberos is a similar but better authentication scheme that is more widely used/understood but won't help you with PKI at all, you get authentication, and that is it.
Comparing Kerberos and SSL/TLS doesn't make sense.
Kerberos is an authentication protocol.
TLS is a protocol for securing the communication between two parties, which relies on mechanisms for authentication and encryption. How they work depend on the chosen cipher suite. Although most usages of TLS (e.g. HTTPS) use X.509 certificates, in which case you're likely to use a PKI for the authentication of the remote party, Kerberos cipher suites can also be used. Few TLS stacks support these Kerberos cipher suites as far as I'm aware (Java does).
It doesn't have to be one or the other. For example, even if you're using SPNEGO (Kerberos) HTTP authentication, it often makes sense to secure the transport using TLS (often with an X.509 certificate on the server side, verified via a PKI). If not, the SPNEGO tokens exchanged in the HTTP headers guarantee the authentication, but the rest of the HTTP messages could have been modified by an attacker.
This could be useful:
http://www.faqs.org/faqs/kerberos-faq/general/section-31.html
Consider that any solution involving Kerberos will be more complicated than SSL because it requires an additional, third component, the Authentication Server, which must be managed and administered (e.g. MS Active Directory) whereas SSL is simply a client/server protocol.
You are mixing stuff. Kerberos is an authentication protocol, SSL ist encryption. Kerberos is the way to go if you are in a corporate environment.
Edit: Kerberos can also encrypt your data traffic transparently. No need for SSL certiticates.
I have to work on an old 1.3 JVM and I'm asked to create a secure connection to another server. Unfortunately the HttpsURLConnection only appears sinc JVM 1.4.
Is there another way to create a secure connection? Is there a library that I could you to add this fonctionnality?
You need to install the Java Secure Socket Extension (JSSE), which used to be required because Sun wouldn't ship it with the JDK because of comedy export restrictions. I had a look on Sun's web site, but the JDK 1.3 instructions are preving elusive. Bear in mind that JDK 1.3 is now end-of-lifed by Sun, so they may not have any information any more.
http://hc.apache.org/httpclient-3.x/sslguide.html
Check out the BouncyCastle implementation. It works all the way down to Java 1.1 and J2ME.
If JSSE doesn't work out for you (from #skaffman's answer, it may be hard to find documentation), you may want to look into some sort of a proxy. You could set up a daemon running on the same local machine (or trusted network), which then forwards the requests over HTTPS to the final end point. You could write this proxy server using a more modern JVM. Your legacy system would then point to the proxy rather than the real service.
Of course, if, by chance, you also have control over the final end point, you could perhaps just put both servers on a VPN.
You might be able to use JSSE.
skaffman links to the SSL guide for jakarta commons HttpClient. HttpClient is a good library for dealing with http.