We have a Java app on Google App Engine. We use Google's custom domains and SSL support. A recent security audit has found two issues that we need to resolve relating to the SSL configuration:
1) The server-side SSL/TLS endpoint is configured to allow weak SSL/TLS cipher suites. Specifically: block ciphers having block size of 112 bits - DES, 3DES and Cipher suites that use block ciphers (e.g. AES, 3DES) in CBC mode.
2) The server-side SSL/TLS endpoint is configured to allow connections using TLS protocol version 1.0 ("TLSv1.0"), which contains known weaknesses
Looking at the App Engine docs, I believe both of these are outside the scope of control we have over the App Engine environment. So we cannot change them unless we put a different loadbalancer or SSL termination point in front of App Engine (Maybe CloudFlare, or our own custom instance for example)
My question is, is there any way to control the SSL and TLS settings in App Engine, and if not, is the best alternative to put CloudFlare (or other proxy) in front of it?
Or, if there is a reasonable defence/explanation of these security weaknesses from Google, I could use that to defend the current configuration Google has for App Engine apps.
I heard back from two incredibly helpful GCE engineers, the gist of it is:
"the settings are shared with the servers serving most Google services, balancing client compatibility with modern best practices"
"[App Engine] runs our standard GFE configuration"
"While we deprecate what we can, we have to balance that with compatibility. Modern browsers do not allow the configuration of a TLS connection to be downgraded and so supporting older protocols like TLS 1.0 doesn't affect them."
So basically, it's good enough for Google, and their security teams are making those security choices based on a number of factors - as they see fit they will deprecate the older versions.
Related
I am working on a credit card support module on a Java-based Web application, for security, we want to have the users use TLS v1.2 supported browsers while viewing the credit card pages
How do I make sure they are compatible?
Note: We don't want to restrict users to other pages if they are not compatible.
This is an old question. Here's some information
How do I detect the TLS version of an HttpServletRequest?
Can I detect the SSL version that a browser supports?
https://gist.github.com/SamuelChristie/13a2a29e74c189bcfd9b - Gracefully Deprecating TLS 1.0
Is there a way to secure Hadoop (version 2.7.2) web user interface - JobTracker, etc. - by using the available Linux accounts of the system? My goal is somewhat similar to what the old mod_auth_pam and the newer mod_authnz_external and pwauth is to Apache. I found a description on how to password protect these interfaces, however it would be much easier if an additional user-password list would not be required to be maintained just for this.
Configuring Hadoop into secure mode and using Kerberos authentication would be one option, but since I have a small cluster with few users, mainly for testing purposes, it would be nice if a not so robust solution would be available for the Jetty web server as well, since my goal is just to make the web UI not public towards the world.
Found this article on Java-based SSO systems and was wondering if it is in any way at all applicable to secure web services.
With secure web services, you need:
A secure transport
Authentication
Digital signage
Encrypted payloads
Usually this can be accomplished with some OASIS-compliant secure framework (CXF, WSS4J, XWSS, etc.) over SSL for the transport.
I'm not familiar at all with Kerberos, JAAS or GSS, but it seems to me that if they can be used to keep secure connections between a client and multiple Java EE apps, why couldn't they be used in tangent with one of those frameworks (like WSS4J) to provide WSS.
Instead of SSL, I could use Kerberos, then let WSS4J handle all the WS-specific stuff.
This way, I could make reusable Kerberos components that could be used both in SSO and for transport layer security in web services.
Am I completely off my rocker here?
Eugie,
The requirements stated are typical. But the details vary to a large degree.
Hence it is not practical to conclude on a single approach or solution.
The requirements need to be further broken down and analysed seperately.
for eg : SSO broadly has two requriments a)Authentication b) Authorization.
You could use single solution for both or multiple solutions for each. An eloborate system could be using multiple authentications at the same time like .. form-based, certifcate based , token based , remote-auth.
In case of authorization we could have a centeralized solution using LDAP/ActiveDirectory/Domino
or a decentralized with all above co-ordinating.
Each of these solutions have limitations , for eg,Kerberos is not effective against password guessing attacks
The choice of security solutions depends on many parameters like
persived threat, cost, prrformace etc..
WS-Security project tries to address many such architectural concerns.
To answer your question -- No you cannot use kerberos for both SSO and transport layer encryption
--Kiran.Kumar
I have a requirement of restricting access of a web application (public url available on www) & allowing it to specified set of clients.
Application details as follows:
Technology Used – JSP / Java EE
Deployed on – IBM Webshpere
My problems are:
01. Can this be achieved through client side SSL certificate?
02. Any mechanism of pulbic key / private key technics availble for this
03. Whether these techniques are dependant on browsers type
Client certificates are standardized in the servlet spec, so yes this is absolutely possible. You specify CLIENT-CERT in your web.xml file.
You will need to set up the keys in WebSphere's keystore (http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/rsec_csiv2cca.html) but this is a proprietary procedure for different containers.
Client certificates are public/private keys, so that should meet your requirement.
There shouldn't be any browser issues, other than giving the users different instructions for different browsers to set up their certificates.
It's in the Java EE spec but has its own problems implementing it. These articles show how to enable and solutions to common issues that arise in such an authentication schema.
I have somewhat of a problem.
We have a centralized interface engine that will talk to a web service that will provide information complement and allow to submit request to external systems. All this is good and fine until we have to integrate this with the required security from this provider.
They issue certificates distributed through smart cards (usb key) that the end user must use to have the software interact with said system (the web services). They insist that the (sometimes multiple) signature be done against the end-user`s certificate on his usb key. The private key is, of course, password protected.
How do I connect Axis2 that will ultimately handle all this to the certificates that are on the end-user`s computer.
The system is mostly legacy thick client application in Delphi 5, the interface engine interacts mostly with the database. Now we have managed to connect a piece of code that effectively connects the end-user`s station to the interface server via a simple TCP socket.
---- EDIT ----
We implemented the solution with customized signature interceptor within CXF (we changed from Axis) that forwarded the message content to a signature proxy which in turn would find and connect the right signature service running on the user-interactive session where the original request came from.
I accepted Eugene's answer because even though we did not use the components he specified we did implement the solution that followed his proposal's general guidelines.
There is no escaping the fact that the signature has to be done in a user-interactive session because of the USB token. Additional constraints were imposed due to the fact we used legacy systems and to the need to have the system work in a shared environment (Remote desktop server). Though it is possible it is not naturally supported by the web service frameworks or cryptographic libraries.
If you have the certificate residing on the client's USB token, then signing (as cryptographic operation) must be performed on the client side. If you can modify this Delphi application, then you can use SecureBlackbox for signing. I know nothing about Axis2, but if it allows creation and plugging custom cryptographic modules, then you make one that will take a hash (which is what is actually signed) and send it to the client for signing.