I have newly started internship in cyber security and the task which i have to do is to make a TLS proxy that only decrypts the incoming traffic from the internet as MITM and forwards decrypted traffic to my private network for analyzing the traffic by logging each and every packet and it make it 185+ GB data approx. the traffic should be both benign and the traffic which contains ransomware (10+ ) which i have to generate by own by using virtual machines (Linux windows mac of different versions ).my good and bad traffic will be in any form i.e. in a email ..form images that contains ransomware in the payload part or from any http or https traffic every transfer mechanism should be in it and they all should be encrypted traffic ..so for dealing with encrypted data our traffic fist passes through an TLS server where it is decrypted and then simply forwarded to inner network of (two to three devices or VMs) for analyzing and maintaining records .i am totally new in this .and i want to accomplish this as soon as possible ..plz provide me the deeper strategy and the procedure ,code of decryption of data TLS and all the things, which i should have to do this task ..so i can understand this easily ..
i have searched the whole web but can't understand that how to making TLS server ,how to forward own encrypted traffic to it and the decryption mechanism of TLS( offloading or termination) for further procedure.
Related
I have a server that has a web server on it. I have setup wireguard vpn between me and server.
Do I need to serve my web server with https for security or wireguard is enough?
You should be fine as long as your web server is listening on the Wireguard interface only (i.e. it is bound to the IP address of the Wireguard interface) so that it is not reachable from outside the VPN. You do not technically need to wrap everything in another encryption layer such as HTTPS, as the only way to establish a connection to the web server is through the VPN, which already provides encryption and authentication.
Beware though that VPN + HTTP does not offer exactly the same security features that VPN + HTTPS does, there are some subtleties. For example, in case your private VPN key is leaked, it could be used to perform a Man-In-The-Middle attack on your connection, whereas using VPN + HTTPS a potential attacker would also need to break through HTTPS, which means either getting privileged access to your machine (since a new private key is generated by your browser on each TLS handshake) or a way to forge a valid CA-signed certificate for your web server's domain (generally not possible). Whether or not you care about this additional layer of security is up to you really.
Is there any autonomous/programmatic way to create many VPS/cloud servers that securely serve a web page that will be accepted by off-the-shelf browsers without buying a new domain name for every VPS? I'm trying to find a solution that is fast, secure, and completely autonomous and it totally stumps me.
Creating many servers programmatically is easy--eg. create DigitalOcean droplets with their API. I also understand how to programmatically setup a web server and secure it with TLS using Let's Encrypt. The part that stumps me is how to setup TLS autonomously for an arbitrary number of VPSs.
What I've tried/though of so far:
Self-signed cert for the IP address of the new VPS won't be accepted by browsers without warnings of plague and death
Let's Encrypt does not support bare IP addresses, only domain names and I can't find any provider that offers bare IP certs with automated and cheap verification
I could buy a wildcard cert and create a new (random?) subdomain for every VPS but then it could take hours for the DNS records to propagate to my end user
I could setup ahead of time a few hundred subdomains, point IP addresses to them and then secure them with a wildcard cert but that would be really expensive, like $4/month per IP address to reserve it
I could use something like DigitalOcean's floating IPs and assign them to the VPS as it's created but again, that costs $4/month to reserve each floating IP
I could use a wildcard cert with pre-setup subdomains that are pointed to by a DDNS and update the DDNS when the new VPS is created. But again, as far as I understand DDNS, it could take hours or at least minutes for the propagation.
I could only secure one server with TLS then proxy traffic from the outside world through that server and then to the VPSs using self-signed certs. This would probably work but add latency and a performance bottleneck. The application is already needing high performance and low latency so this is not attractive.
Is there something I haven't thought of? Anyone with out of the box ideas?
Any DNS or DDNS gurus out there who know how to instantly assign a new subdomain to a new IP address? Can you avoid caching delays with random subdomains? Any cert authorities who issue automated bare IP address certs?
Thank you!
Background: My client sells a piece of software that runs only on Linux and they want to enable their customers to user that software occasionally in the cloud from any browser. My plan is to program a cloud hypervisor that serves a web interface, takes a request from the customer to use the software, spins up a new DigitalOcean droplet with an image that runs the software, connects the customer's browser to a VNC-to-websocket proxy, then destroys the droplet when the session is over.
To automate the infrastructure give a try to terraform for now probably is the most consistent and "easy" way of creating all your instances.
Now for using TLS on all your domain/subdomain probably the easiest solution is to delegate this to CloudFlare (considering you app is a web page HTTP/HTTPS):
Cloudflare-issued SSL certificates cover the root-level domain (eg- example.com) and one level of subdomains (eg- *.example.com)
In case you need to get the certificate and later use it like for a local web instance or an SMTP server you can still use lestencrypt but do the verification via DNS, this way, you don't need a web server and can "programmatically" manage your certificates, the how you deploy them or put them in your instances is another topic, maybe for that "ansible" could help to automate that process.
I have an F5 load-balanced 4-server cluster environment that I'm building, so I'm looking to centralize our certificates to prevent needing to install them all on every server. Windows 2012 / IIS 8 seems to have centralized certificates, but that is only to secure my endpoint in IIS for inbound traffic.
What about for outbound traffic? They all will be initiating TLS transactions to external entities, so I need a way to store all these on a single server and have each of the IIS boxes "tap into" that cert store for the private and public keys that are necessary to send that TLS message.
Any suggestions?
You're looking for an HSM which the F5 will support and IIS also supports a few major vendors (Thales and Safe-Net both have IIS supported HSMs). They're not cheap from what I remember but that's exactly what you're looking for.
If you don't want to go that route, you can opt for the dirty solution of using the BIG-IP as your cert store and rely on self-signed certs on the IIS pool members.
Inbound: Incoming traffic terminates on BIG-IP using the valid CA-signed cert SSL Client profile. BIG-IP re-encrypts to IIS using a generic SSL server profile. Not pretty but it works.
Outbound: You would have to use the BIG-IP as the default gateway of the IIS server so you can direct the outbound TLS from BIG-IP instead of IIS directly.
Devcentral: SSL Acceleration - Can I encrypt outbound traffic
Hope this helps.
-Chase
Can we ignore SSL verification for local network. My case is-
I have two applications deployed in a system. These two applications cannot communicate through internet, due to some security constraints. the two applications can communicate using their private IPs. But the certificate issued by CA is valid only for the public IP (accessible from internet), so when they tries to do a HTTP connection, it throws a Subject Alternative Name invalid exception.
I cannot use alternate certificate.
Please suggest if we can configure Java / JREs of the applications to ignore SSL validation?
Please suggest any alternate solution, if any.
It sounds to me like you might just be better off using HTTP on the local network.
If you need transport layer security on your LAN, you can probably use a VPN or SSH tunnel instead. And it sounds to me like you don't really need this, as you're OK with ignoring SSL handshake errors, which makes using SSL in the first place kind of moot.
You can set up your servers to listen on two ports, one for external requests over HTTPS, and one for internal requests on HTTP.
You can either set up your firewalls so that HTTP is only available from LAN IPs, or alternatively only listen on localhost and use a VPN or SSH tunnel to the target server and do the requests via the tunnel.
I'm doing a bit of research on this, so is there any security risk if we have the SSL certificate installed at the load balancer instead of the server? And what is the industry best practice to install SSL certificates? on server, load balancer, or ADC?
This is probably better off on serverfault, but I'll give it a shot here.
There's no increased security risk for the SSL certificate itself just because you put the SSL certificate on the load balancer, assuming the load balancer is configured correctly and won't serve up the private key. This risk exists on any server, load balancer or not, a new OS compromise or attack might, although it's unlikely, allow that to happen.
However depending on how you do it traffic behind the load balancer could be sent unencrypted, if the load balancer only talks HTTP to the content servers. So you need to configure the forwarded connections to use HTTPS as well, either using internal certificates and your own CA, or by installing the externally face HTTPS cert on the content servers (and you'll need to do this if you're aiming for PCI compliance).
Remember there's also a load risk, encryption is expensive, and by putting the cert on the load balancer it increases the, errr, load, on it. If the load balancer is already over stretched this may be the final straw. If you're looking at lots of transactions then you tend to see a hardware SSL device sitting before the load balancer which takes care of the SSL traffic, then talks HTTP to the load balancer, which talks HTTP to the content servers. (Again this needs to be HTTPS if you are aiming for PCI compliance)
Here are the implications I could think of:
Unless you re-encrypt the traffic between the SSL accelerator and the final server, traffic on the internal network will be in clear text. That could cause other security flaw to become more dangerous. Depending on what your legal and contractual requirement are regarding the data you're transferring, it might be unacceptable.
You will lose te ability to use X509 certificate to identify the clients. This could be a problem or not depending on what you're doing.
As for certificate management, you're storing the private key on the SSL accelerator instead of the server. This could actually be an advantage because if the web server gets compromised, the attacker will still have no access to the private key themselves and therefore will not be able to steal them.
There are many levels of load balancing. You don't have choice but to put cert in the load balancer in most popular configurations.
For example, if you are proxying the HTTP traffic in the load balancer, it has to terminate the SSL connection so it must have the cert.
Normally, the load balancer lives in the secure zone so you don't have to use SSL between balancer and your server. If that's not the case, you can use SSL again but you defeat the purpose of the SSL acceleration feature on most switches.