Score:0

is an HTTP connection secure if it points to a VPN client IP address setup on local server?

es flag

I have a local server setup in my LAN with an always on openVPN client. Therefore the public ip address of this server is not the same as the public ip of the router it is connected to.

If I own a domain name, and add a DNS A record that points to the server's public ip, (ip set by vpn), then I access my web services with http://my-domain.com:<port>, how vulnerable to attacks is this connection?

Does adding an SSL certificate remove the above vulnerability if any?

Score:1
se flag

If I understand you correctly you have a server on your LAN, which is reachable from the public internet.

This means if there are vulnerabilities in the server (like an insecure or outdated setup of an web application like Wordpress or similar), they could be exploited by an attacker on the public internet. Moreover, the attacker could propagated from this exploited server than to other systems on your internal LAN.

That a VPN is involved to make this server reachable is irrelevant, since it does not add protection to the server and only changes with which public IP it is reachable.

Similar HTTPS does not reduce the attack surface, since it only protects the communication between client (and thus also the attacker) and server but not the server itself. In fact, HTTPS adds additional complexity to the setup and thus might actually increase the attack surface.

bcsta avatar
es flag
Thanks for this information. So from what I understand, something like cloudflare which would act as a security layer in front of any web application would be the best course of action in terms of vlunerability.
Steffen Ullrich avatar
se flag
@bcsta: not having any vulnerabilities in he first place would be the best. Cloudflare itself is only a CDN, but you can add WAF functionality for some protection. But don't assume that a WAF will protect against arbitrary security issues in a web application.
bcsta avatar
es flag
I agree not having vulnerabilities is the main priority. But with a variety of web services, I am reluctant to completely trust their systems... an extra third party security layer should, in theory, add protection.
Steffen Ullrich avatar
se flag
@bcsta: I agree that additional security layers reduce the attack surface. But it is unclear how much they actually help in your case since nothing is known of what you are running on the server. Note also that these layers don't protect against an attacker laterally moving into your LAN once they've exploited your server. It is not a good idea but expose a potentially vulnerable system to the internet (and thus to the attacker) and at the same time treat it as a trusted system inside the LAN.
bcsta avatar
es flag
The services I am using all have standard encryption with login security. One of them has a 12 word seed as encryption.
Steffen Ullrich avatar
se flag
@bcsta: *"standard encryption with login security. One of them has a 12 word seed as encryption.... "* - which does not say much about the actual security of the system. Implementation might be wrong, authentication bypass for critical actions might be possible, ... - these bugs happened even for major applications like MS Exchange, repeatedly. I recommend that you don't let you blend by buzzwords and big numbers and instead have a look at [OWASP Top 10](https://owasp.org/www-project-top-ten/). And again - don't trust a system on your LAN which is also exposed to the internet.
Sabre avatar
cn flag
As I stated before, there is no such thing as secure, there is mitigation, backup, and recoverability. NSA CIA pentagon, Fortune 500 companies, major banks, and other govts not just US. All get hit regularly. as Stephen pointed out, the flagship products of the most trusted platforms in the world get broken into routinely. Why? Because it is impossible to prevent. All ou can do is implement the best you can with whatever tech is available, and then focus the remainder of your time on recoverability. Security is not a software or a configuration, it is a methodology.
Sabre avatar
cn flag
So to answer the question "how vulnerable to attacks is this connection?", the answer is "as vulnerable as it is valuable" and valuable, may not be direct, you could be a step stone to another target, or just an asset in tow until needed. ALL systems connected to the internet have value as a target, it is complete disregard for any security to assume otherwise. Even the ones that are not have value (Stuxnet anyone?) You are only as secure as what you never knew you did not know. So do your best to protect, spare nothing in recoverability and mitigation.
Score:0
cn flag

IMO, the answer is no. HTTP could still be intercepted on the localhost of the server or client. IN todays security world the smash and grab is over, the sit and listen is more fruitful. Consider a scenario where the system does have an exploitable vulnerability, and ne'er-do-well gains access. Then sits and siphons off user data interacting with the site. For instance try capturing packets on your local machine with Wireshark to an HTTPS site. Things like fiddler and burpsuit can do it with a blatant MITM and easily detectible method, but passively its a no. HTTPS all the way for a multitude of reasons. MY $0.02...

HTTPS secures at the socket level.

When you commented "not having any vulnerabilities in the first place would be the best." Yes, this is true, but never ever will any service be able to claim this honestly, and if they do they are ignorant at best, salesmen at worst. Vulnerabilities are discovered every day in things that were completely unknown the day before. Including TLS, but it is the best we have, so it should be used.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.