Tag Info

New answers tagged

0

Pros - Easy to implement network wide (DHCP server and a local DNS server are enough) - Easy to block (just add it to a list in the DNS server and route it to a bogus address or local address) - Easy to Bypass (if needed its easy to bypass) Cons - Easy to bypass, just use a different DNS or add an entry to the hosts file is enough. - Is considered "Bad ...


0

The advantage is that it is simple and reasonably effective against casual issues. The disadvantage is that it is easily bypassed. Check out OpenDNS as they offer this kind of service & I use this on the home network to help protect things.


1

Any application can easily submit any DNS resolution request. There are numerous libraries available and programmers can choose to perform the resolutions whichever way they want. For example, in Python it's one line of code (maybe two) import dns.resolver answers = dns.resolver.query('dnspython.org', 'MX') To link an actual application to the UDP ...


1

Even with your own nameserver, you'd be either recursively pulling dns entries from elsewhere or doing your very own mitm zones, which is why dnssec is there. On a related note, looking at the osi model, you could also depend fully on ssl certs on the browser to ensure you don't get redirected to a phishing site of some sort, as a kind of L7 guarantee of ...


0

Cache poisoning by implementing cryptographic signatures for zone transfers. If you wish to encrypt payloads then use IPSec


2

The primary defense against MITM attacks during issuance is to perform the validation check -- observing the server or its DNS -- from many geographically dispersed locations. This is how many CAs today operate for automated web checks to detect forgery and fraud. From what I heard in the IRC room, Let's Encrypt will be doing the same for all of the ...


7

Yes, the protocol you describe only ensures that "the person who picks up the phone at awesome bank" when you call them, is the same person who picked up the phone at awesome bank when the Let's Encrypt server called them. If I have the ability to intercept calls to awesome bank both from Let's Encrypt and from you, then I can fool you. Ideally what you'd ...


4

The use of an automated check is not unique to this CA, but is common for entry-level certificates. As stated in other answers, there are 3 levels of certificate in use: Doman Validation proves only that you had control of the domain at the time the certificate was issued. (And that the certificate hasn't been explicitly revoked since then.) Organisation ...


32

What prevents me from using this attack on the Let's Encrypt server, and obtaining a certificate for awesomebank.example, and then using it to MITM customers of AwesomeBank without being detected (because I have a valid certificate)? Nothing. If you own the network, then you own the network. And DV type certs (see below) rely on the network for proof of ...


6

Let's Encrypt is designed to help against a range of attacks and to push the generalization of TLS usage to have a globally safer and more private internet. It is aimed more precisely to remove technical and financial constraints which may prevent some webmaster to use TLS certificates more broadly. However, as any security measure, this will not be a ...


0

Running requests via proxy will break a lot of default options for tools. If you look into how proxychains works you'll find: SOCKS is a layer 5 protocol. That means it doesn't care about anything below that layer in the OSI model! That means that you can't use it to tunnel protocols operating below layer 5. This includes things such as ping, ARP, etc. ...


1

The answer depends on different factors. A few that may or may not apply: What protocol is it? (For example UDP is more prone to security issues in this case as it works statelessly and you might achieve something with a single spoofed packet). Do you consider attacks or only data access. (See above: you might be able to do a DoS attack for a faulty UDP ...


1

Also consider that the hostname localhost is not exactly the same as the IP 127.0.0.1 (it naturally needs to be resolved first), and in most situations relies on either an entry in the hosts file or a resolver/dns server capable of resolving 127.0.0.1. So, be sure you can strictly specify 127.0.0.1 instead of localhost when implementing security measures, ...


6

If the service provides a web interface it might be vulnerable to CSRF attacks, XSS attacks or "same site" scripting. All of these can be triggered by just visiting the attackers external website, which by itself might be caused by malvertising or phishing. For these attacks it does not matter if the service is listening only on localhost, because it is only ...


8

A potential vulnerability would be to compromise a low-privilege account/service and use that as a pivot to access the localhost-bound service. I usually prefer UNIX sockets for that purpose as you can apply user/group permissions on them (that will be transparently handled by the OS, the user won't have to keep yet another password). Plus, they're also a ...


16

The first and main thing is to ensure that the firewall on your host is configured to properly drop incoming packets with source or destination address set to 127.0.0.1. Under normal circumstances, there should be no packet coming from the network and showing such addresses. However an attacker may attempt to forge such packets in order to reach your local ...



Top 50 recent answers are included