I use mitmproxy to gather intel from outbound AS2 (HTTP) requests leaving our network. The schema goes like this:
Mendelson AS2 ➡ mitmproxy ➡ partner AS2 server
↘
redis
Where possible, I need to verify all SSL certs to make sure the business connection is safe. Some partners use less known CAs which I then add to a truststore used by the ssl_verify_upstream_trusted_ca option.
Some partners though don't really care about security and I need to trust their certificates no matter what. How do I do that in mitmproxy? Disabling the verification entirely isn't an option.
Thank you.
It's been a while since I've tried to solve this using a custom addon and it seems to work fine so I'll share it here:
https://gist.github.com/jsmucr/24cf0859dd7c9bba8eb2817d7b0bf4b6
This approach has a bit of disadvantage and that's the fact that it doesn't check if the peer certificate changes.
Related
I may not be doing something right, security wise, so please do inform me.
User visits the site (and is forced to use HTTPS). Valid certificate. They connect via WSS to a "middleman" server. Third-party orgs expose a normal WS server to the internet, and broadcast it's public address/port to the "middleman" server, which is then broadcast to the user.
So, the user, on this HTTPS site, gets a url such as ws://203.48.15.199:3422. Is there any way I can possibly allow this sort of connection to happen?
One such way is to allow the "middleman" to also be a proxy - every third-party server address is assigned a path on the WSS-enabled middeman server. User's would connect to wss://example.com/somepath and I would simply proxy it back to the third-party, insecure websocket. The downside is that I must maintain that proxy, which defeats the purpose of allowing third-parties to even run their own server.
Any ideas?
Is there any way I can possibly allow this sort of connection to happen?
This is a form of active mixed content. All recent browsers, such as Firefox and Google Chrome prohibit this kind of content, much like they prohibit a secure page (HTTPS loaded page) from loading insecure JavaScript.
The reasoning is fairly straight forward: it undermines the purpose of HTTPS in the first place.
The "correct" way to fix this is to force all 3rd party to HTTPS on their websockets as well and avoid the whole issue.
One such way is to allow the "middleman" to also be a proxy
Yes. You could set up a proxy server for your 3rd parties that you want to allow proxying. There are numerous examples of doing this nginx scattered around the internet. A simple example might be:
# untested configuration
server {
listen 443 ssl;
ssl_certificate /etc/ssl/certs/cert.pem;
ssl_certificate_key /etc/ssl/private/cert.key;
location /3rdpartyproxy {
proxy_pass http://203.48.15.199:3422;
proxy_http_version 1.1;
proxy_set_header Upgrade websocket;
proxy_set_header Connection upgrade;
}
}
Something like this may work, but keep in mind it is not in the best interest of your users. The connection between your proxy and the 3rd party is still insecure and vulnerable to all the same attacks that regular HTTP is.
Another thing to watch out for is to make sure your proxy isn't used incorrect by other parties. I've seen some people set a proxy with a dynamic path and would proxy that traffic to wherever. Something like:
ws://myproxy.example/203.48.15.199/3422
Then configure the web server to proxy it to whatever was in the URL. This seems like a nice solution because it'll just do the right thing depending on whatever the URL is. The major down side to it is, unless you have some kind of authentication to the proxy, anyone can use it to proxy traffic anywhere.
To summarize:
You cannot allow ws: on https: pages.
The best solution is to move the burden on to the 3rd parties. Have the set up proper HTTPS. This is the most beneficial because it fully serves the purpose of HTTPS.
In can proxy it. The caveat being that it is still insecure from your proxy to the 3rd party, and you now need to manage a proxy server. Nginx makes this fairly easy.
If you go the proxy route, make sure it's configured in a manner that cannot be abused.
If I require SSL, does this mean they won't be able to just publish an IP to connect to?
Getting an HTTPS certificate requires a domain name. To be more specific, getting a certificate for an IP address is possible, but it very out of the ordinary and far more effort than getting one for a domain name.
How much more of a burden is it?
That's mostly a matter of opinion, but it will mean picking a domain, registering it, and paying to maintain the registration with a registrar. The cost varies, but a domain can usually be had for less than $15 a year if there is nothing special about the domain.
Can the process of exposing HTTPS be entirely automatic?
Getting an HTTPS certificate is mostly automate-able now. Let's Encrypt offers HTTPS certificates for free (really, free, no strings, is now a wildly popular Certificate Authority). Their approach is a bit different. They issue 3 month certificates, but use software called CertBot that automates the renewal and installation of the certificate. Since the process is entirely automated, the duration of the certificate's validity doesn't really matter since it all just gets renewed in the background, automatically.
There are other web servers that use take this a step further. Apache supports ACME (the protocol that Let's Encrypt uses) natively now. Caddy is another web server that takes HTTPS configuration to the absolute extreme of simplicity.
For your 3rd parties, you might consider giving them examples of configuration that have HTTPS properly set up for various web servers.
I would love just a little more description on "certs for IP addresses" possibility as I feel you glossed over it.
IP addresses for certificates are possible but are exceedingly rare for publicly accessible websites. https://1.1.1.1 is a recent example.
Ultimately, a CA has to validate that the Relying Party (the individual or organization that is requesting a certificate) can demonstrate control of the IP address. Section 3.2.2.5 of the CA/B Requirements describes how this is done, but practically it is left up to the CA to validate ownership of the IP address. As such "Domain Validated" certificates are not eligible for certificates with IP Addresses. Instead, "Organization Validated" certificates, or OV, is required at a minimum. OV certificate issuance is more stringent and cannot be automated. In addition to proving ownership of the IP address, you will need to provide documentation to the identity of the Relying Party such as a drivers license for an individual, or tax documentations for an organization.
Let's Encrypt does not issue certificates for IP addresses, so you would likely have to find a different CA that will issue them, and likely pay for them. Registering a Domain Name for the IP address will likely come out to be more cost effective.
I'm not aware of any CA that will issue certificates for an IP address in an automated fashion like Let's Encrypt / CertBot.
Using a domain name affords more flexibility. If an IP address needs to be changed, then it is a simple matter of updating the A/AAAA records in DNS. If the certificate is for the IP address, then a new certificate will need to be issued.
There have been historical compatibility issues with IP addresses in certificates for some software and browsers.
An idea, but you still need your server to behave as a reverse-proxy : instead of example.com/somepath, implement thirdparty.example.com virtual host for each of your third parties. You then need a wildcard certificate *.example.com, but this prevents people trying to access example.com/somepathdoesntexist
Due to a couple of issues with my host, I'm unable to use a SSL-certificate on my server (I'm not ready to change provider just yet), and can't therefore use HTTPS. This server will communicate with a couple of client-computers and will transfer data that's somewhat secret.
Would it be reasonable to simply use AES encryption (encryption on client before sending, decryption on server before processing) instead of HTTPS?
This depends on your deployment environment.
Replacing SSL/TLS (and HTTPS) with your own encryption protocol for use by a web browser is always a bad idea, since it relies on JavaScript code delivered insecurely (for details, see this question on Security.SE, for example).
If the client isn't a web browser, you have more options available. In particular, you can implement message-level security instead of transport-level security (which is what HTTPS uses).
There are a number of attempts to standardise message-level security with HTTP. For example:
HTTPsec had a public specification (still available on WebArchive), but a commercial implementation. I'm not sure whether this has been widely reviewed.
WS-Security, oriented towards the world of SOAP.
Perhaps more simply, if you want to re-use existing tools, you could use S/MIME or PGP (in the same way as you would for e-mails) to encrypt the HTTP message entities. Unlike HTTPS, this won't protect the URL or the HTTP headers, but this might be enough if you don't put any sensitive data there.
The further down you go with "raw encryption" yourself (using AES directly, for example), the more likely you'll have to implement other aspects of security manually (typically, verifying the remote party's identity and dealing with the problem of pre-sharing the keys).
If you have a small list of clients that don't change often, you could implement your own SSL-Tunnel using SSH. On the clients do a;
ssh -D 4444 nulluser#example.com -N
where nulluser has no shell or file access on example.com.
Then add a foxyproxy whitelist setting - so that for example.com the client browsers use the localhost:4040 proxy.
It's a hack, it's totally unscalable, but it would work as I say for a small, static number of clients, and it has the advantage of not reinventing any wheels while being totally secure.
i have a windows 2008 server and a comodo wildcard cerificate.
i also have a couple of applications running under this certificate.
the application and the certificate work fine and are correctly installed.
i have a gprs module from telit that without ssl works fine but when enabling ssl althougth it works it makes 45seconds in handsake to authenticate the server certification.The delay is surely from the handshake because later on the communication is fast enough.
i am searching quite a while for possible problems. i am leaning to believe that the validation of the certification chain is slow.
how can i reduce this time? do you have any other ideas of possible errors or setting issues?
What is likely happening is that you have not installed the intermediate certificates in the chain on the server. This causes the server not to send those to the client and the client needs to fetch them on its own, which causes the delay. Ensure that all certs in the cert chain, except the root, are present in the local machine Intermediate CAs store.
You can use Wireshark or similar tool to look at the network traffic and see what certificates are being sent from the server to the client. If you could capture the client network traffic, you can see whether my theory above is correct or not and what is causing the delay.
I have a couple questions about SSL certificates.
I never used them before but my current project requires me to do so.
Question 1.
Where should you use SSL? Like I know places like logging in, resetting passwords are definite places to put it. How about once they are logged in? Should all requests go through SSL even if the data in there account is not considered sensitive data? Would that slow down SSL for the important parts? Or does it make no difference?(sort of well you got SSL might as well make everything go through it no matter what).
Question 2.
I know in smtp you can enable SSL as well. I am guessing this would be pretty good to use if your sending say a rest password to them.
If I enable this setting how can I tell if SSL if it is working? Like how do I know if it really enabled it? What happens if the mail server does not have SSL enabled and your have that boolean value enabled. Will it just send it as non SSL then?
With an SSL connection, one of the most expensive portions (relatively speaking) is the establishment of the connection. Depending on how it is set up, for example, it might create an ephemeral (created on the fly) RSA key for establishing a session key. That can be somewhat expensive if many of them have to be created constantly. If, though, the creation of new connections is less common (and they are used for longer periods of time), then the cost may not be relevant.
Once the connection has been established, the added cost of SSL is not that great although it does depend on the encryption type. For example, using 256-bit AES for encryption will take more time than using 128-bit RC4 for the encryption. I recently did some testing with communications all on the same PC where both client and server were echoing data back and forth. In other words, the communications made up almost the entire cost of the test. Using 128-bit RC4 added about 30% to the cost (measured in time), and using 256-bit AES added nearly 50% to the cost. But remember, this was on one single PC on the loopback adapter. If the data were transmitted across a LAN or WAN, then the relative costs is significantly less. So if you already have an SSL connection established, I would continue to use it.
As far as verifying that SSL is actually being used? There are probably "official" ways of verifying it, using a network sniffer is a poor man's version. I ran Wireshark and sniffed network traffic and compared a non-SSL connection and an SSL connection and looked at the raw data. I could easily see raw text data in the non-SSL version while the SSL "looked" encrypted. That, of course, means absolutely nothing. But it does show that "something" is happening to the data. In other words, if you think you are using SSL but can recognize the raw text in a network sniff, then something is not working as you expected. The converse is not true, though. Just because you can't read it, it does not mean it is encrypted.
Use SSL for any sensitive data, not just passwords, but credit card numbers, financial info, etc. There's no reason to use it for other pages.
Some environments, such as ASP.NET, allow SSL to be used for encryption of cookies. It's good to do this for any authentication or session-ID related cookies, as these can be used to spoof logins or replay sessions. You can turn these on in web.config; they're off by default.
ASP.NET also has an option that will require all authenticated pages to use SSL. Non-SSL requests get tossed. Be careful with this one, as it can cause sessions to appear hung. I'd recommend not turning on options like this, unless you really need them.
Sorry, can't help with the smtp questions.
First off, SSL is used to encrypt communications between client and server. It does this by using a public key that is used for encryption. In my opinion it is a good practice to use it for as anything that has personally identifiable information or sensitive information.
Also, it is worth pointing out that there are two types of SSL authentication:
One Way - in which there is a single, server certificate - this is the most common
Two Way - in which there is a server certificate and a client certificate - the client first verifies the server's identity and then the server ids the client's id - example is DOD CAC
With both, it is important to have up to date, signed, certificates by a reputable CA. This verifies your site's identity.
As for question 2, yes, you should use SSL over SMTP if you can. If your emails are routed through an untrusted router, they can be eavesdropped if sent without encryption. I am not sure about the 'boolean value enabled' question. I don't believe setting up SSL is simply as easy as checking a box though.
A couple people have already answered your Question 1.
For question 2 though, I wouldn't characterize SMTP over SSL as protecting the message. There could be plenty of points at which the message is exposed. If you want to protect the message itself, you need S/MIME, or something similar. I'd say SMTP over SSL is more useful for protecting your SMTP credentials, so that someone cannot grab your password.
I'm looking for options for securing UDP traffic (mainly real-time video) on a wireless network (802.11). Any suggestions apart from Datagram Transport Layer Security (DTLS)?
Thanks.
You must be more clear about the attacks you are trying to defend against. For instance if your only concern is spoofing then you can use a Diffie–Hellman key exchange to transfer a secret between 2 parties. Then this secret can be used to generate an Message Authentication Code for each packet.
If you need any more protection I strongly recommend using DTLS. It should be noted that all TLS/SSL connections can be resumed so you can cut down on the number of handshakes. Also, certificates are free.
Are you trying to wrap an existing application or writing your own? What client server setup do you have? Do you want to prevent snooping or tampering?
I am assuming here that you
are developing an application
are trying to prevent snooping
have access to client and server.
The simple approach is to use any off the self strong encryption. To prevent tampering use any signing algorithm with a private/public key scheme. You can use the same key pair for encryption and authentication.
The drawback of this approach is that it is on layer 7 and you have to do most of the work on your own. On the other hand, DTLS is a viable option...
Have you considered IPSEC? This article provides some good guidance on when and when not to use it.
You can look into ssh with port forwarding. That comes at the cost of maintaining a TCP connection over which the UDP traffic can be secured.