I am looking for advise on how to encrypt a command line application.
I envisage a command line app that interacts with a web service. I want the messages between the app and the web service to be encrypted.
I know that SSL certificates are the common use for encrypting with web services however if i have a single app that many people take and use on the command line of their machines each will have to have a SSL certificate.
Is there another way to encrypt the communication?
Note: I am building both the web service and command line application so can match up the encryption if needed.
Thanks
I want to encrypt the transmitted data i.e., the http headers and body.
HTTPS with a server certificate (no need to client certificate in your case) can do it. Nobody between your client and your server will be able to read or modify the content of the transmitted data (url, headers and body).
The server will present his certificate to your client. With that your client can confirm the identity of the server. Then they can exchange informations securely.
If you need to identify the client to your server, you can use a client certificate (but it's not the only method)
Note that because of DNS and SNI, somebody on the network can still know which domain your client connect to.
Related
So i have my site on hosting company, and this company support let encrypt certificate, so i generated it and now the site is running with https protocol.My server side(spring boot application web service oriented started on VPS) for this site is on another company. My questions are:
How can i use this generated certificate on my server side part,
is it possible, what should i do?
What i need to provide to the server, and all things that are needed the server to work?
When i was without the certificate everything worked perfect, but right now on the server side i get
java.lang.IllegalArgumentException: Invalid character found in method name. HTTP method names must be tokens
and in the browser i get
net::ERR_SSL_PROTOCOL_ERROR,
when I`m trying the get resources from server.
From the hosting company i can get everything connected to the certificate
It seems that you are passing HTTPs traffic to web server which "talks" in plain HTTP.
Normally SSL termination is done on software like Apache HTTPD or Nginx.
Then you configure it to act as reverse proxy to your actual Spring boot application running in JVM.
You can also configure your JVM webserver (Jetty,Tomcat .. whatever you have) to use your Let's encrypt certificate, but I have doubt that certbot will be able to easily renew them.
I am trying to insert a header on all HTTPS requests that passes my proxy server.
I read that HTTPS request headers can not be tampered with.
Is there any way that I can insert a header on HTTPS requests?
Only if the proxy is the endpoint of the TLS connection with the client (i.e. the proxy decrypts the requests). Otherwise it won't actually see any HTTP headers at all, just TCP sessions containing encrypted data.
It is common for a reverse proxy local to the web server(s) to terminate TLS connections for performance - the Web server can dedicate more resources to serving applications because it doesn't need to spend CPU cycles on de/encryption.
If you do this, your server certificate must identify the proxy server, not the web server. Otherwise clients will get a warning about the identity of the server differing from the certificate identity.
If you don't control or trust the infrastructure between the proxy and your server you could re-encrypt the ongoing requests.
Unless you are willing to terminate the SSL connection on your proxy, no you can't. This is one of the main goals of SSL. The data and that includes the headers are encrypted from the client to the server.
If you decide to terminate / intercept the SSL connection on your proxy, the clients will get a warning in their browsers. If you are in charge of all the browsers of all the clients you would be able to install a custom certificate and the clients wouldn't get warned anymore.
I have a java application that runs on client machines that receives ajax requests from web applications. Some of these web applications that would like to use the service are served only under https.
I have the java app now accepting and handling SSL requests just fine, but I must first navigate to the server in a browser and accept the cert.
What is the best method of having a 'real cert' installed as part of this java app that listens on https://localhost:my_port?
On windows, it seems I can have an installer add a self signed cert to the machines accepted list. I had also thought about getting a verified cert for thisApp.myDomain.com and then changing host files to point that address to 127.0.0.1, but changing host files seems malicious and I worry about that being picked up by anti-virus.
The 'main' application is a web based system. Some users of this web based system would like to be able to print to special printers on designated computers. The java app is to be installed on those computers, the web application then sends ajax requests to the java app, which interacts with the printers. End users need to be able to install this java service with an easy, one-click type of installer. The web app is run from a browser on the machines doing the printing, hence localhost.
As stated earlier, the web apps need to connect to the web server (currently residing with amazon) via https. The connection to the localhost print server does not need to be https for any reason other than Chrome complains about insecure content, and chrome is currently the most widely used browser by our users.
Any thoughts or suggestions?
If by "real" cert, you mean one that signed by a trusted CA, then I think that the answer is that you probably can't. I don't think a trusted CA will issue one for you.
The answer I linked to above suggests that you set up your own CA by getting a CA cert. The other alternatives are a self-signed cert for 127.0.0.1, or tweaking your DNS resolution (e.g. via the client machines' "hosts" files) so that some name with a valid cert resolves to a loopback address on your client machines.
BTW - turning off certificate verification is not the way to go. It is better to add a self-signed certificate to the trusted cert list of (for instance) the user's browser.
If I was in your situation, I think I'd change whatever it is that requires HTTPS for requests on 127.0.0.1. Either don't require HTTPS for the requests, or change the IP address to the client's own IP address.
I try to install self signet certificate on client machine - but fails. Don't remember what was the issue. So I turn off verification for certificate in client code.
You can read about it here.
So, I have a working protocol that the Client needs to authenticate with user and password to login on the server. Then server and client would trade messages and files. It´s all working OK and I´m using Input/Output Stream for that.
I need to add encryption to the conversation and user/password authentication too. I dont want to store a symmetric key inside my jar, So I think I will need a public/private keys for that.
I know I could use the public/private encryption to send a symmetric key, but I really dont know how to do that in Java. And I think I could maybe just use encryption on the messages and not on file transfer.
I googled for it and found various ways of using cryptography with java sockets, whats the best(correct) way? Using CipherOutput(Input)Stream? Or is there another way?
If someone could post a piece of code I would be grateful
SSL. See javax.net.ssl and the JSSE Reference Guide.
If you are in a bind for time, you can piggy back on SSH port forwarding.
You will setup firewall rule on your server that would allow direct access to clear text port only from the firewall host.
Then on a client you will setup a port forwarding SSH session ( -L option on ssh client ).
The client machine then will talk clear text to a local host on the forwarded port and all conversation will be encrypted by SSH tunnel.
I have two java applications that need to talk to each other over an encrypted TCP socket, but they don't need to authenticate each other (one will accept() a connection from the other). Can anyone point me to a tutorial/code-snippet that will help me set these up?
I'm looking for something fairly simple and I'd like to not have to supply any keystore or truststore material.
EDIT: I should be more specific here. I meant that they don't have to authenticate each other via SSL. I have some non-trivial authentication that I have to do at the application level, so I can't use any sort of SSL-based authentication scheme.
Also, some of the links in the answers posted so far (as of noon 3/10/2010) require keystore files. Is there a simple way I can programmatically generate the keys I need?
To reiterate Chris Jester-Young's advice - if you don't have authentication, then you might be communicating securely, but you have no idea who you're communicating securely with. You could simply be communicating very securely with the bad guy himself (who is relaying everything you're saying onto the person you hoped you were talking directly to).
However, there is a quite lightweight authentication scheme that might suit your purposes, called TOFU (Trust On First Use). This is where you use SSL and generate self-signed certificates for each side - however you do not skip certificate validation. Instead, on the first connection with a given peer you accept any certificate and store it locally; on subsequent connections with that peer, you only accept that saved certificate. This is similar to the way that ssh works by default for host authentication, and provides authentication of the "the guy I'm talking to now is the same guy I was talking to yesterday" variety.
You can use the anonymous Diffie-Hellman ciphersuites if you insist on ignoring Chris Jester-Young's sage advice. Those ciphersuites are not enabled by default, you have to explicitly enable them, for example by using the SSLSocket.setEnabledCipherSuites() method.
If you absolutely do not want to use SSL with certificates, you can roll your own, though it won't be as secure obviously. I'm just improvising here, mixing a little asymmetric crypto with port-knocking.
First, create a random RSA key pair in the client, in-memory, no need to store it anywhere. Client then connects to server using a plain Socket, and upon connection, sends the server the public key (encode as you wish, so that you can read it easily on the server). Server then generates a random 128-bit key, starts ANOTHER ServerSocket in a random port, and encrypts the 128-bit key and the new server port number, using the client's public key, and sends the data back to the client. Server must wait for a short period of time to receive a connection from the same client on the new port.
Client closes connection, deciphers data, and opens a new Socket to the server on the specified port. Then both client and server must wrap the socket's InputStream and OutputStream on a CipherInputStream and CipherOutputStream using AES/CBC/PKCS5Padding (or RC4 if you prefer) with the specified 128-bit key. Voilá, you have a secure connection between client and server, without any authentication.
If you want to handle authentication you can do so over the secure connection, or on the first connection the server can have RSA key pair as well, they exchange keys and the server can send a challenge to the client (the server sends the challenge to the client using the client's public key and the client responds to the challenge using the server's public key). But that's unnecessarily complicated and I think you'd be better off using standard SSL with keystores anyway... perhaps you can get create an in-memory KeyStore on the client and send it to the server as explained above using the first connection (encrypt the keystore with the server's public key) and then you can set up the second connection to use SSL with that keystore which is temporary and will be discarded when the client disconnects.