I'd like to use an alternative SSL library like GnuTLS on JBOSS for secure connection. Am I right that GnuTLS can't be used on JBOSS since it's written in C? Apart from that, does JBOSS only support OpenSSL and JSSE (keytool) libraries?
The reason I'm considering the move is for security reasons. Will this make any real change since all SSL libraries use the same algorithms like RSA?
So, if I keep using OpenSSL or keytool, will the application stay equally secure?
Related
I'm trying to modify my Go client and server code to use TLS. In Python I can do ssl.create_default_context(purpose=ssl.Purpose.SERVER_AUTH)
which will automatically load the system's trusted CA certs and uses secure settings. I'm wondering if there's something similar in Go where it will automatically load trusted CA certificates. I'm not sure exactly what to put for the client's certificates.
I think you're looking for tls.Config. But keep in mind that Python's ssl.create_default_context exposes a lot of SSL internals that most people don't need, and you might not need a tls.Config in your application at all. For instance, net/http has a http.ListenAndServeTLS() function which starts a TLS web server with sensible defaults and whatever certificates you provide.
We have a legacy web application that runs in a tomcat under java 6, upgrading to 7 or 8 is infeasible as the application needs significant work to allow this and the fixes required are too large to implement in a legacy application. We now have a requirement to connect outbound (i.e. as a client) over TLS 1.2 however java 6 only supports 1.0. We use Apache as our web-server and OpenSSL for incoming connections and this happily supports TLS 1.2 etc.
Has anyone had to address a similar issue, or can you comment on the following potential work arounds:
Loopback to localhost (or otherwise redirect) and use OpenSSL to create a TLS 1.2 connection,
effectively an internal proxy
can openssl be a client?
do we need s_client?
Use our current the firewall to upgrade the connection
this would need to be selective
Obviously implementing this will depend on the firewall
Use “Bouncy Castle” (https://www.bouncycastle.org/)
Don't use openssl's s_client for this - it's slow, and intended more for debugging/testing.
Try using stunnel. It's designed for use cases like yours, and you can find plenty of example configs to get you started. You'd want to make sure to include the sslVersion = TLSv1.2 directive in your configuration to force use of TLS 1.2.
I am using Https and Tcp over SSL in java application with keystores and truststores. I use selfsigned certificates generated by java keytool. I am came to know about HeartBleed vulnerability with openSSL, do I need to change any implementation from java side or I am on safe side. can anyone please give details.
Java does not use OpenSSL, although some Java applications like Tomcat can. As you're using keystores and truststores, you must be using JSSE rather than OpenSSL.
I don't really know much about IT and have been working in software development for 3 years. I have used version control with Github and Bitbucket, but I really don't know how SSH, SSL, HTTPS works. Can anyone explain them in the context of version control with a cloud service like Github? Why is TLS not used? A user case example would be most helpful. High-level is fine.
Firstly, while a number of people think SSH relies on SSL, it doesn't: it's an entirely different protocol. The fact OpenSSH relies on OpenSSL might be one of the causes of this confusion (whereas in fact OpenSSL can do much more than SSL).
Secondly, TLS is essentially a newer version of SSL, and HTTPS is HTTP over SSL/TLS. You can read more about this in "What's the difference between SSL, TLS, and HTTPS?" on Security.SE, for example.
One of the major differences (in the context of GitHub and Bitbucket) has to do with the authentication mechanisms. Technically, both password and public-key authentication can be used with or on top of SSL/TLS and SSH, but this is done rather differently. Existing libraries and tool support also matters.
GitHub (with Git) relies on an SSH public key for authentication (so that you don't have to store or use a password every time).
Public key authentication in SSH uses "bare keys", whereas you'd need a certificate for SSL/TLS (and in 99.9% cases that's going to be an X.509 certificate). (A certificate binds an identity to a public key by signing them together.) GitHub would have to use or set up a CA, or perhaps use various tricks to accept self-signed client certificates. All of this might be technically possible, but this would add to the learning curve (and may also be difficult to implement cleanly, especially if self-signed cert tricks were used).
At the moment, GitHub simply lets you register your SSH public key in your account and uses this for authentication. A number of developers (at least coming from the Git side) would have been familiar with SSH public keys anyway.
Historically, Git over SSH has always worked, whereas support for HTTP came later.
In contrast, Mercurial was mainly an HTTP-based protocol initially. Hence, it was more natural to use what's available on HTTPS (which would rule out using X.509 certificates if they're deemed too complicated). AFAIK, SSH access for Mercurial is also possible.
In both cases (Git and Hg), the SSH public key presented during the connection is what lets the system authenticate the user. On GitHub or Gitlab, you always connect as SSH user git, but which key you use is actually what determines the user in the system. (Same with Hg on Bitbucket: ssh://hg#bitbucket.org/....)
I doubt if it is a good question for StackOverflow, however.
All these protocols are used as (secured) channel for Git data exchange. And, when you see 'SSL' most likely SSL/TLS is meant - just to not type both abbreviations. TLS is a further development of SSL protocol.
I have academical project to build communicator with Public Key Infrastructure. For communication between server and clients I'll use SSL/TLS and I need for them certificates. I have to build Certificate Authority with CRL and I can do this with openSSL but this tool is only good for manual administrative not for making certificates automatically in remote CA.
To be clear: Clients must register and login to communicator using certificates but it should be made invisible for them. I've tried running openSSL as process in Java but it's not working properly - my previous problem.
Have you any good advice for making simple PKI?
You can use and extend EJBCA. It takes some getting used to but it has support for some HSM's, and it should not be hard to create a small PKI with it. Open source.
A replacement for simple operations of OpenSSL, would be Bouncy castle. To have better CA support you should also use the EJBCA.
To create certificates automatically in the client (I assume you use a client web browser) is a bit trickier. Some browser can generate private client keys and then get them signed by the CA server.
Generating client side certificates in browser and signing on server
In that case, I would also use the EJBCA to make it manageable.