5 ms·

Yes, we have found that the set of Internet Protocols were designed before the kind of security we expect today were appreciated. You are correct that we are n

by dwviel 9y ago

Yes, we have found that the set of Internet Protocols were designed before the kind of security we expect today were appreciated. You are correct that we are not professional crypto people. But, crypto is just the starting point for cybersecurity that is a necessary but not sufficient condition for a secure system. What we did was start with crypto, and related technologies like cryptographic hashes, secrets, etc. and built a secure messaging system using the principles mentioned above. This has so far shown itself to be highly successful. Hi, The reply buttons have apparently been disabled. I guess cybersecurity is too controversial for HN ;) I will reply here instead. @theamk 1) UDP leaks information, thereby violating the C in CIAA. TCP is subject to the SYN resource exhaustion attack, and is connection oriented which is brittle. Both are vulnerable to packet replay attacks, which is a particularly troubling problem for controls. 2) The pen testers that evaluated our technology we believe to be highly competent. We are open to having the pen testers (US only) of your choice test our technology. @pritambaral Yes, see the quotes on our website. And we do in house testing as well. We are happy to have pen testers (US only) try to defeat the system.

theamk 9y ago
Glad to hear from authors! Question 1: So how is your solution better than UDP/QUIC or TCP/TLS? Yes, you have to properly tune and use protocols, by padding the data properly, and by setting up DDOS mitigations. Still, it will be much less work that writing a new protocol from scratch, and it will be better than your protocol in every single aspect. Question 2: What do you mean "highly successful"? I did not see anything in the whitepaper (but I have not read it very carefully), and the website has two quotes from hilariously incompetent pentesters. Do you have any other evidence of success?
pritambaral 9y ago
> ... built a secure messaging system using the principles mentioned above. > This has so far shown itself to be highly successful. What do you mean by this? Can a system be "highly successful" at being secure without having been targeted, or have you actually hired testers and/or auditors to attack/study the system?
- theamk 9y ago
  Well, you saw the quotes on the website, they did hire the best pentesters! For example, one pentester ran "nmap", which did not find any ports open, so he said "There doesn't seem to be an available service to attack." This means the system is SUPER SECURE.
  - dwviel 9y ago
    These were just a selection of quotes that looked good on the web site, particularly the "GREAT JOB!" quote. That's kind of nice to see.
    - theamk 9y ago
      Well, you may want to choose different quotes, or even better, make whole reports available. Because if your pentesters do not know what to do when nmap fails, this means they must be pretty clueless and thus their reports do not have much value.
theamk 9y ago
Reply to your message edits: > 1) UDP leaks information, thereby violating the C in CIAA. Which information? Properly encrypted UDP only shows destination IP and port number. Your protocol shows destination IP and protocol number (99) -- since very few people use it, protocol 99 is as distinct as UDP port. Moreover, if you are concerned with UDP port leak, you can just use a random destination port on server, or masquerade as some other UDP protocol. There is no such option with current ControlMQ system > TCP is subject to the SYN resource exhaustion attack, and is connection oriented which is brittle. You do know about SYN cookies, right? And you know that SYN flood is easily defeated now -- for example, out of 5 most significant DDOS attacks in 2016 (https://www.tripwire.com/state-of-security/security-data-protection/cyber-security/5-significant-ddos-attacks-2016/ https://www.tripwire.com/state-of-security/security-data-pro...) , none used SYN flood. > Both are vulnerable to packet replay attacks, which is a particularly troubling problem for controls. Any control connection should use encryption. Every popular encryption method (including TLS and QUIC) protects against replay attacks. > 2) The pen testers that evaluated our technology we believe to be highly competent. Well, all I have is front page quote, and I see the words "We were unable to [...] observe [...] the message traffic" and "TCP and all the UDP ports only list that they are open/unfiltered". This apparently means they could not even use wireshark to observe the IP message traffic -- they just ran "nmap" and found not ports. This is pretty sad for a pentester. I would expect to see mentions of DOS attacks and fuzz testing. For example, what happens if I just start sending random packets to your daemon? How many packets per second it can handle before it fails over? What if I compromise a client, extract a session establishment key from it (assuming you have one), and start to establish new sessions? how many will your server handle before failing?
- dwviel 9y ago
  Good points. The port number typically indicates a service that is publicly known and repeatable. This is leaked information, as each service will have a unique port number. The IP protocol of 99 is used for all communications so no differentiation of network traffic can be made using this information. SYN cookies can be a solution, but it has limitations, and to overcome those limitations requires changes to the TCP protocol. It is also preferable not to use TCP for controls in order to avoid the coupling caused by connections. The network between components may also be unreliable thus causing the need for regular reconnections. Replay attacks protection by TLS, etc uses sequence numbers which expects a continuous connection. There is the setup phase that must be taken into account and then the entire series of packets from that point on can be replayed. The goal is to run on unreliable networks so connections would constantly need to be reestablished. We consider DOS attacks to be attacks on the network rather than the component. The number of packets/sec that the daemon can handle is computer resource determined. But, >1000/sec is typical in our testing on commodity H/W. It has never failed due to load in thousands of hours of testing. If a client (first peer) is compromised then it can send any message it wants to the second peer with which it is configured to communicate. But, only properly formed, valid range messages will be accepted. Let’s say that the receiving component controls a motor that has a valid engineering range of 0 -1000 RPM. If a nefarious command came in to spin to 2000 RPM that would be rejected. The server (second peer) is not connection based so it will handle whatever packet arrive at the rate it can, and drop the rest on the floor. So, overall we believe it is simpler and less error prone to use our protocol then set up all these complicated extra configurations.

by dwviel 9y ago

theamk 9y ago

Glad to hear from authors! Question 1: So how is your solution better than UDP/QUIC or TCP/TLS? Yes, you have to properly tune and use protocols, by padding the data properly, and by setting up DDOS mitigations. Still, it will be much less work that writing a new protocol from scratch, and it will be better than your protocol in every single aspect. Question 2: What do you mean "highly successful"? I did not see anything in the whitepaper (but I have not read it very carefully), and the website has two quotes from hilariously incompetent pentesters. Do you have any other evidence of success?

pritambaral 9y ago

> ... built a secure messaging system using the principles mentioned above. > This has so far shown itself to be highly successful. What do you mean by this? Can a system be "highly successful" at being secure without having been targeted, or have you actually hired testers and/or auditors to attack/study the system?

theamk 9y ago
Well, you saw the quotes on the website, they did hire the best pentesters! For example, one pentester ran "nmap", which did not find any ports open, so he said "There doesn't seem to be an available service to attack." This means the system is SUPER SECURE.
- dwviel 9y ago
  These were just a selection of quotes that looked good on the web site, particularly the "GREAT JOB!" quote. That's kind of nice to see.
  - theamk 9y ago
    Well, you may want to choose different quotes, or even better, make whole reports available. Because if your pentesters do not know what to do when nmap fails, this means they must be pretty clueless and thus their reports do not have much value.

theamk 9y ago

Reply to your message edits: > 1) UDP leaks information, thereby violating the C in CIAA. Which information? Properly encrypted UDP only shows destination IP and port number. Your protocol shows destination IP and protocol number (99) -- since very few people use it, protocol 99 is as distinct as UDP port. Moreover, if you are concerned with UDP port leak, you can just use a random destination port on server, or masquerade as some other UDP protocol. There is no such option with current ControlMQ system > TCP is subject to the SYN resource exhaustion attack, and is connection oriented which is brittle. You do know about SYN cookies, right? And you know that SYN flood is easily defeated now -- for example, out of 5 most significant DDOS attacks in 2016 (https://www.tripwire.com/state-of-security/security-data-protection/cyber-security/5-significant-ddos-attacks-2016/ https://www.tripwire.com/state-of-security/security-data-pro...) , none used SYN flood. > Both are vulnerable to packet replay attacks, which is a particularly troubling problem for controls. Any control connection should use encryption. Every popular encryption method (including TLS and QUIC) protects against replay attacks. > 2) The pen testers that evaluated our technology we believe to be highly competent. Well, all I have is front page quote, and I see the words "We were unable to [...] observe [...] the message traffic" and "TCP and all the UDP ports only list that they are open/unfiltered". This apparently means they could not even use wireshark to observe the IP message traffic -- they just ran "nmap" and found not ports. This is pretty sad for a pentester. I would expect to see mentions of DOS attacks and fuzz testing. For example, what happens if I just start sending random packets to your daemon? How many packets per second it can handle before it fails over? What if I compromise a client, extract a session establishment key from it (assuming you have one), and start to establish new sessions? how many will your server handle before failing?

dwviel 9y ago
Good points. The port number typically indicates a service that is publicly known and repeatable. This is leaked information, as each service will have a unique port number. The IP protocol of 99 is used for all communications so no differentiation of network traffic can be made using this information. SYN cookies can be a solution, but it has limitations, and to overcome those limitations requires changes to the TCP protocol. It is also preferable not to use TCP for controls in order to avoid the coupling caused by connections. The network between components may also be unreliable thus causing the need for regular reconnections. Replay attacks protection by TLS, etc uses sequence numbers which expects a continuous connection. There is the setup phase that must be taken into account and then the entire series of packets from that point on can be replayed. The goal is to run on unreliable networks so connections would constantly need to be reestablished. We consider DOS attacks to be attacks on the network rather than the component. The number of packets/sec that the daemon can handle is computer resource determined. But, >1000/sec is typical in our testing on commodity H/W. It has never failed due to load in thousands of hours of testing. If a client (first peer) is compromised then it can send any message it wants to the second peer with which it is configured to communicate. But, only properly formed, valid range messages will be accepted. Let’s say that the receiving component controls a motor that has a valid engineering range of 0 -1000 RPM. If a nefarious command came in to spin to 2000 RPM that would be rejected. The server (second peer) is not connection based so it will handle whatever packet arrive at the rate it can, and drop the rest on the floor. So, overall we believe it is simpler and less error prone to use our protocol then set up all these complicated extra configurations.