Suppose I want a secure TLS communication between me and myschool.edu. Which of the following should I trust to preserve confidentiality, integrity, and authenticity. Here are the options and my analysis.

a) The entire network between me and myschool.edu. (I can't, a hacker could have compromised something in between)

b) Computers on my local and home network. (I can't, they could hack my information)

c)The operators of .edu's Authoritative DNS server. (I can trust them, there is only one owner of the .edu brand)

d) The operators of myschool.edu. (I can trust them since I want to communicate with them. Am wondering, what if an individual operator is bad )

e) myschool.edu's CA. (I think I can trust the CA)

f) All the CA's configured into myschool.edu's software. (Since the world has very few CA's, I can trust them).

g) All the CA's configured into my web browser. (I trust CA's)

h) The designers of the cryptographic algorithms. (I can trust them, I assume TLS has good algorithms. I don't know whether its the only encryption that will happen)

Did I analyze these options correctly? I want someone else's point of view on these options.

  • DNS servers are increasingly under attack and notoriously difficult to secure properly. – schroeder May 10 '15 at 2:29
  • The biggest question in your analysis is: what do you want to secure against? What's the risk you want to mitigate? – schroeder May 10 '15 at 2:29
  • You don't decide who to trust based on what preserves security. You decide who to trust for what sorts of things based on who you think is trustworthy, and then hope you can (while only trusting those guys) ensure security. As for DNS servers, who says you're talking to the real DNS server instead of an MitM? – cpast May 10 '15 at 4:30

Some things to consider when dealing with TLS as a protocol.

  1. The payload of the communicating packet is encrypted. The 'dst' & 'src' packet attributes are not, which allows for any device within the network route to intercept your communication.

  2. Numerous attack against the SSL & TLS protocol over the years have allowed for the following attack types (not a complete list);

    • a) cipher down grades - During the initial handshake of the communication each party (prior to certificate verification) performs an agreement on the cipher, hashing algorithms and additional cryptography protections to use during the 'session'. In this particular scenario if a MITM attack is in progress and weaknesses exist, the chosen cipher can be negated to a weak cipher allowing for further decryption/attacks (or as the pros term it 'crypto analysis')

    • b) weak random number - All crypto relies heavily upon truly random numbers. Previous exploits here relied upon flaws within random numbers when private keys are generated. This allowed for easily factored cipher text attacks.

    • c) memory leaks - Most people are aware of the 'heart bleed' attack which allowed a specific handshake negotiation to trigger a memory leak of the affected device which lead to exposure of system accounts, private keys and whatever else was in the buffer at the time of the attack.

    • d) certificate spoofing - While not as common CA signatures on fake TLS certificate attacks have been known to happen. This usually is the result of a certificate authority getting attacked and having their root certificates stolen and used to sign fake certificates leading browsers to believe they are legitimate.

There are many, many more vectors of attack regarding TLS/SSL communications. If you wish to keep abreast of these 'confirmed' flaws go to the source.

That being said there are also mitigation strategies you can employ in your environment as well as protecting yourself, unfortunately it takes some research to do so.

In regards to mitigating flaws within the DNS protocol there are several methods of minimizing the possibility of a MITM scenario.

  1. DNSSEC - Which employs cryptographic signatures and encrypted DNS queries between zones and clients.

  2. Whitelists - Deny by default. Then configure zones to only accept updates from a whitelist of devices.

  3. arptables - A method of filtering layer two protocols such as DNS & DHCP.

While that is also not a comprehensive list of mitigation strategies for a server/client configuration of DNS queries and zone updates it should give you some information with which to start.

| improve this answer | |
  • From the information above, it looks like I can really trust any option because it could have a problem. Is there anything to trust about TCP? – user124627 May 11 '15 at 0:53
  • The retransmitting of failed packets comes to mind – jas- May 11 '15 at 2:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.