I want to strictly enforce TLS on all inbound/outbound emails from gmail (gsuite basic) for a particular organization/domain. I did read this article:
https://support.google.com/a/answer/2520500?hl=en
It asks to create an address list to setup inbound/outbound rule to enforce TLS. However I want to have TLS enforced irrespective of address and want to enable following behavior:
Outgoing mail: Mail won't be delivered and will bounce. You'll get a non-delivery report (NDR). Only one send attempt is made (no tries again).
Incoming mail: Mail is rejected without any notification to you, although the sender will receive an NDR.
Any suggestions on how this can be accomplished?
You can’t do that, in fact based in this article at point 6.:
https://support.google.com/a/answer/2520500?hl=en
“You must create a domain or address list to enforce TLS compliance for any inbound or outbound messages”
Gmail by default will use TLS, however, if the destination domain can’t establish TLS connection, Gmail will do an insecure connection. However, nowadays all domains are all by default establishing TLS connection and transmitting data over it. It’s rare you will find a domain that doesn’t support TLS connection.
Therefore, first of all, you should know which domains you usually contact that doesn't support TLS connection, and listed in the TLS compliance rules.
The idea of this policy is not making a long list of domains but only a few that customers already know that they don’t support TLS connection hence list them on the TLS.
There is a feature for a higher message encryption but is available for G Suite Enterprise edition: https://support.google.com/a/answer/6374496?hl=en
In fact what it may be a workaround is to Send and receive your email first to an external server that allows you to achieve this.
If this is the case you should Set up:
Set up an inbound mail gateway: https://support.google.com/a/answer/60730?hl=en
Set up an outbound mail gateway: https://support.google.com/a/answer/178333?hl=en
An consider a third party tool as : https://zix.com/products/email-encryption
I'm making app with VS 2017 and Xamarin. I plan to send username and password (in request body) to my server with httpClient (Android), PostAsync().
I have seen examples like the answer at
Send HTTP Post request in Xamarin Forms C# and just wonder if there is a way to check that the data beeing sent is really encrypted.
I know from https://blog.xamarin.com/securing-web-requests-with-tls-1-2/ that the httpClient would automatically encrypt messages.
Greetings
If you connect to your server using SSL the data you send will be encrypted. This can be achieved by simply using the https:// prefix when connecting to your server as opposed to the regular http prefix.
As you said that you are using SSL on your server I shall not go into the ins and outs of implementing it as it is very different on every platform. For anyone reading this in the future a great starting point is using LetsEncrypt if you're on a budget as it is free (although you do have to refresh your certificate every so often).
To verify that the data is encrypted you can use a program called Wireshark whilst debugging in an Android Emulator. The instructions are pretty clear within wireshark but on sending the request from your android phone select the domain/ip from the wireshark panel and view the information from that request. If you are using SSL right the data should be encrypted.
Is there a Groovy way to open a SSL connection to a server with client side authentification without using the JVM keystore?
I want to enable users to upload a public key over a website and then access a REST API on their server in a secure way. So I can have a lot of different keys which have to be loaded during runtime. I don't know if this is even possible using keystores.
I am looking for a solution, where I can just provide the keystring on connection initialization.
In the docs for the Google Channel API it says:
"A channel is a one-way communication path through which the server sends updates to a specific JavaScript client identified by its Client ID."
In their diagrams they show a client sending its state with a POST. This seems like it would be slow. Can the client communicate with the Channel API through a socket? Or must it send via POST?
POST is a message type indicator and message format.
Major edit after more research!
See Google API doc
Looks like messages from the browser to the server do indeed open new HTTP-level connections to send a POST message. Whether a new TCP/IP connection is needed or not depends on the browser's management of TCP connections--new browsers do a better job of this. See wikipedia HTTP persistent connection
Re: This seems like it would be slow. Usually the browser traffic is asymmetrical--with most of the data from the server to the browser. Comet will help that use case.
Re: Can the client communicate with the Channel API through a socket? Do you mean IP socket? Browsers don't have an api for that. Do you mean "web socket?" I'm 98% sure it wouldn't work to combine the two techniques. But you could try...
I am creating a secure web based API that uses HTTPS; however, if I allow the users to configure it (include sending password) using a query string will this also be secure or should I force it to be done via a POST?
Yes, it is. But using GET for sensitive data is a bad idea for several reasons:
Mostly HTTP referrer leakage (an external image in the target page might leak the password[1])
Password will be stored in server logs (which is obviously bad)
History caches in browsers
Therefore, even though Querystring is secured it's not recommended to transfer sensitive data over querystring.
[1] Although I need to note that RFC states that browser should not send referrers from HTTPS to HTTP. But that doesn't mean a bad 3rd party browser toolbar or an external image/flash from an HTTPS site won't leak it.
From a "sniff the network packet" point of view a GET request is safe, as the browser will first establish the secure connection and then send the request containing the GET parameters. But GET url's will be stored in the users browser history / autocomplete, which is not a good place to store e.g. password data in. Of course this only applies if you take the broader "Webservice" definition that might access the service from a browser, if you access it only from your custom application this should not be a problem.
So using post at least for password dialogs should be preferred. Also as pointed out in the link littlegeek posted a GET URL is more likely to be written to your server logs.
Yes, your query strings will be encrypted.
The reason behind is that query strings are part of the HTTP protocol which is an application layer protocol, while the security (SSL/TLS) part comes from the transport layer. The SSL connection is established first and then the query parameters (which belong to the HTTP protocol) are sent to the server.
When establishing an SSL connection, your client will perform the following steps in order. Suppose you're trying to log in to a site named example.com and want to send your credentials using query parameters. Your complete URL may look like the following:
https://example.com/login?username=alice&password=12345)
Your client (e.g., browser/mobile app) will first resolve your domain name example.com to an IP address (124.21.12.31) using a DNS request. When querying that information, only domain specific information is used, i.e., only example.com will be used.
Now, your client will try to connect to the server with the IP address 124.21.12.31 and will attempt to connect to port 443 (SSL service port not the default HTTP port 80).
Now, the server at example.com will send its certificates to your client.
Your client will verify the certificates and start exchanging a shared secret key for your session.
After successfully establishing a secure connection, only then will your query parameters be sent via the secure connection.
Therefore, you won't expose sensitive data. However, sending your credentials over an HTTPS session using this method is not the best way. You should go for a different approach.
Yes. The entire text of an HTTPS session is secured by SSL. That includes the query and the headers. In that respect, a POST and a GET would be exactly the same.
As to the security of your method, there's no real way to say without proper inspection.
SSL first connects to the host, so the host name and port number are transferred as clear text. When the host responds and the challenge succeeds, the client will encrypt the HTTP request with the actual URL (i.e. anything after the third slash) and and send it to the server.
There are several ways to break this security.
It is possible to configure a proxy to act as a "man in the middle". Basically, the browser sends the request to connect to the real server to the proxy. If the proxy is configured this way, it will connect via SSL to the real server but the browser will still talk to the proxy. So if an attacker can gain access of the proxy, he can see all the data that flows through it in clear text.
Your requests will also be visible in the browser history. Users might be tempted to bookmark the site. Some users have bookmark sync tools installed, so the password could end up on deli.ci.us or some other place.
Lastly, someone might have hacked your computer and installed a keyboard logger or a screen scraper (and a lot of Trojan Horse type viruses do). Since the password is visible directly on the screen (as opposed to "*" in a password dialog), this is another security hole.
Conclusion: When it comes to security, always rely on the beaten path. There is just too much that you don't know, won't think of and which will break your neck.
Yes, as long as no one is looking over your shoulder at the monitor.
I don't agree with the statement about [...] HTTP referrer leakage (an external image in the target page might leak the password) in Slough's response.
The HTTP 1.1 RFC explicitly states:
Clients SHOULD NOT include a Referer
header field in a (non-secure) HTTP
request if the referring page was
transferred with a secure protocol.
Anyway, server logs and browser history are more than sufficient reasons not to put sensitive data in the query string.
Yes, from the moment on you establish a HTTPS connection everyting is secure. The query string (GET) as the POST is sent over SSL.
You can send password as MD5 hash param with some salt added. Compare it on the server side for auth.