Hello Corda experts: I have a question about Conclave beta 3. I downloaded conclave SDK hello world project, and ran it according to conclave document successfully. But when I tried to use RestTemplate to access an external https API from the enclave, it is failed. And the error message is "java.security.NoSuchAlgorithmException: Default SSLContext not available". Since the default JVM for enclave is Avian, I doubt that maybe Avian doesn't support SSL. Does any expert know the root cause and how to solve it? Thanks very much.
At this time Conclave doesn't support outbound SSL connections. It's something we'd like to support and is a high priority but it must be done very carefully. For example, we will have to ship a root cert store with the enclave embedded in the binary (or a signed version that's injectable by the host), there are questions about how to handle expiry checking given that the host controls the clock, whatever credentials are used to access the external service (if any) need to be securely sealed and stored, it will only make sense to support OCSP Stapling as a form of revocation checking with all others needing to be disabled and so on.
You don't technically need us to solve these issues for you. You can load the SSLEngine and relay packets from it in and out of the host using the call mechanism. It'd be a bit awkward but should be possible.
Related
I would like to know if it's possible to make G-WAN 100% compatible with HTTP/2 by using for example the solution nghttp2 (https://nghttp2.org)
Sorry for the late answer - for any reason Stackoverflow did not notify us this question and I have found it only because a more recent one was notified.
I have not looked at this library so I can't tell for sure if it can be used without modifications, but it could certainly be used as the basis of an event-based G-WAN protocol handler.
But, from a security point of view, there are severe issues with HTTP-2, and this is why we have not implemented it in G-WAN: HTTPS-2 lets different servers use the same TCP connection - even if they weren't listed in the original TLS certificate.
That may be handy for legit applications, but that's a problem for security: DOH (DNS over HTTP-2) prevents users from blocking (or even detecting) unwanted hosts at the traditionally used DNS requests level (the "hosts" file in various operating systems).
In facts, this new HTTP standard is defeating the purpose of SSL certificates, and defeating domain-name monitoring and blacklisting.
Is it purely a theoretical threat?
Google ads have been used in the past to inject malware designed to attack both the client and server sides.
When using java APNs, if using the same program to send messages to different applications, it is required to use different certificates. Does switching certificates causes disconnection/reconnection and is it considered a bad practice? (as APNs would like to have persistent connections thus preventing denial of service).
I don't think it's possible to switch a certificate for an existing connection. At least I'm quite sure it's not possible in Java SSLSocket (since it is constructed by an SSLSocketFactory, and you use the certificate in one of the parameters required for constructing that factory).
You should maintain an open socket for each application you are sending notifications to. This way you don't have to close the socket and open a new one each time you need to switch certificates.
I have created a back-end/processing/statistics for POS transactions for a retail store chain. The thing is, now it is time to move from alpha to beta, and we need some sort of safety for the incoming data. And this is where I am lost. How do I implement some resemblance of security in this kind of system?
What I have come up with is a simple asymetric key/value pair, that is unique for each POS system, where the server has all of the private keys, and each pos has the public part of this exchange. In addition to this, all of the data exchange is sent via HTTPS.
Does this kind of thing make sense? Or is there a better way to keep the data safe?
P.S. Since there is a need to reconfigure each POS seperately, that is in no way connected to this system, having to do manual work at each POS is not a problem.
You'd like to accomplish 2 things:
1) Encrypt the traffic so that it is hidden from outsiders (confidentiality). You can accomplish this quite easily simply by enforcing that SSL is used for traffic between the client(s) and the server. The server will require an x509 certificate to accomplish this.
2) Ensure that all traffic coming to the server originates from a trusted client/POS (integrity). You can accomplish this using a couple of different techniques, both of which require an x509 certificate installed on each client (POS) system:
a) Require that all requests to the server be accompanied by client certificates. In this scenario, the client (POS) has a x509 certificate installed, for which it is able to access its own private key (the server does not, and should not have this private key, it belongs to the client). The server is configured to require client certificates with each request, it also is configured to validate that the client certificate presented does indeed match one of the POS systems. So if you add a new POS later, you need to make a change to the server ensuring that it will consider the new POS cert valid. Here is a description of the protocol for your own enrichment, you shouldn't need to know exactly how it works (because most tools IIS, Apache, etc. will abstract much of this for you) but it does demystify things a bit. http://publib.boulder.ibm.com/infocenter/tivihelp/v5r1/index.jsp?topic=%2Fcom.ibm.itim.infocenter.doc%2Fcpt%2Fcpt_ic_security_ssl_authent2way.html
OR
b) Require that all requests to the server are digitally signed by trusted clients. Public key (asymmetric) encryption allows you to sign a message. Basically it is signed with the client's (POS) private key, and then anyone (including the server) can verify its integrity by validating the signature using the client's public key. Many tools will actually encrypt and sign the message, which is OK, but if you're already using SSL and performance is a concern, you don't need to encrypt twice. If security is more important than performance, encrypting twice can't hurt. Here is some more info on digital signatures: http://www.cgi.com/files/white-papers/cgi_whpr_35_pki_e.pdf
So you should have a pretty good plan of how to proceed. Feel free to ask around here when you set out to implement these solutions, as there are a lot of things that usually don't work the first time around and debugging it is often difficult. I do recommend a tool called Fiddler or WireShark, which can help debug web services to some extent. Be sure that your client(s) can access their own private keys, and that the certificates of the clients are trusted by the server. Good luck.
http://fiddler2.com/
I'm building a client-server application and I am looking at adding failover to the client so that when a server is down it will try to connect to another available server. Are there any standards or specifications covering server failover? I'd rather adopt an existing standard than implement my own mechanism.
I don't there is, or needs to be any. It's pretty straight forward and all depends on how you can connect to your sever, but basically you need to keep sending pings/keepalives/heartbeats whatever you want to call em, and when a fail occurs (or n fails in a row, if you want) change a switch in your config.
Typically, the above would be running as a separate service on the client machine. Altenativly, you could create a method execution handler which handles thr execution of all server calls you make, and on Communication failure, in your 'catch' block, flick your switch in config
You're question is very general. here are some general answers:
Google for Fault Tolerant Computing
Google for High Availability Solutions
This is usually handled at either the load balancer or the server level. This isn't something you normally do in code at the client.
Typically, you multihome the servers each having their own IP + one that is shared between all of them. Further, they communicate with each other over tcp for the heartbeat to know which is the Active node in an Active / Passive cluster.
I can't tell what type of servers you have, but most of the windows servers can do this natively.
You might consider asking the question at serverfault to see how to properly configure your servers to support this.
Some phones only prompt the user for permission the first time a connection is made. Others pop up the permission prompt whenever the MIDlet attempts to make a HTTP connection! What are the options if we want to suppress the prompt?
Can we sign the JAR using only one CA (Certificate Authority) and have it work on all devices? Do we have to pay for a signature on every release?
Is it an option to create our own CA certificate and tell our customers to install it on there device?
Alternatively, it seems that plain socket connections do not suffer so. Is there a free implementation of HTTP on top of TCP for J2ME?
Some phones allow you to change the setting manually to set once per session. Or try adding
MIDlet-Permissions: javax.microedition.io.connector.http
to the jad file.
Yes, if the build is signed with the root certificate that is available on most devices, Verisign Class 3 certificate, for example
As a security measure, devices don't allow you to install your own certificates, even if it is obtained from a CA.
Plain socket connections may add overhead in processing of the data in the client side. Also some security issues are also involved.
Signing the JAR is not guaranteed to suppress these prompts on all handsets and all networks. It may work on some. AFAIK you usually need to sign per build; so if you use the same build on many handsets, you need to sign only once.
You could write your own implementation of HTTP over sockets, but beware that Socket implementations do not allow access to ports 80 and 8080 (again AFAIK).
Your best option when experiencing multiple prompts for HTTP is to direct the user to the MIDlet permissions setting in their handset menu; this should be changed to "ask once".
HTH,
funkybro
Java Verifieds UTI root certificate is not on all handsets/network combinations, the same is true for other domains in the trusted third party such as Verisign and Thawte (for these bodies in particular Motorola devices)
It is fair to say that the UTI certificate is probably the one to choose to give you the most coverage across handsets
To suppress the HTTP connection prompt, signing an app is the only option. Another would be to get preload on a pre-market phone, but even the handset manufacturers require signed jad/jars.
Making a set of jad/jar work on different devices is not dependent on signing but how you design an app. If you can address this then yes, you can have one signed jad/jar work on multiple devices.
I do not know about creating our own certs and asking customers to install them. I dont think it works as I dont think it is possible.
HTTP over TCP is a fairly easy implementation, provided you know what you are doing, but I dont know of any free implementations of it.
Get it Java Verified and you will find that on all networks and phones - the user will get prompted only once each time they start the app to authorise a connection.