Timeline for security protocol against attacks on SSL/TLS
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 4, 2017 at 16:02 | history | tweeted | twitter.com/StackSecurity/status/860162703566020608 | ||
| May 4, 2017 at 9:28 | vote | accept | peter | ||
| May 4, 2017 at 0:55 | answer | added | Strigo | timeline score: 2 | |
| May 3, 2017 at 22:58 | answer | added | Jean-Michel Florent | timeline score: 0 | |
| May 3, 2017 at 9:44 | comment | added | oleksii | @peter, which cert client side or server side? These are different attacks. Your protocol will have numerous vulnerabilities anyway. It takes many bright people and a long time to design, test and validate a new security protocol. | |
| May 3, 2017 at 7:57 | comment | added | Steffen Ullrich | @peter: if they already have a symmetric key shared in a secure way then they don't need to use TLS. The whole point of the TLS handshake is to get a shared symmetric key in a secure way in order to encrypt the traffic. But however the parties got the shared key: it should be kept secret and not entered it into some form they've got over a potentially insecure connection as you propose. Because this allows the attacker to grab this shared secret. In other words: no, your idea does not add security. | |
| May 3, 2017 at 7:48 | comment | added | peter | @oleksii I am already using two-way authentication. But if an attacker somehow manages to get hold of one of the certificates, does my protocol ensure me that the attacker is still unable to read / send any valid message? | |
| May 3, 2017 at 7:33 | comment | added | peter | @SteffenUllrich suppose the clients and the owner of the server establish the symmetric key face to face. The owner of the server then stores it on the server, and the clients learn the 16 characters (128 bit key) by head. When the clients enter the symmetric key in the html input box, it is not sent to the server, but stored as a variable in the client's browser. Do you think my two examples are correct, i.e. that this protocol provides extra security in a situation where an attacker is able to act as a client or as the server? | |
| May 2, 2017 at 16:45 | comment | added | oleksii | The biggest flaw is that you are attempting to create a new security protocol. Just stop. Search for two-way authentication in TLS (using client-side certs is a widely known and used practice). | |
| May 2, 2017 at 16:31 | comment | added | Steffen Ullrich | How does the client and server get a shared symmetric key in the first place so that the client is able to enter the key the server already has? I doubt that you understand what TLS is actually doing: providing a safe way to exchange a symmetric key and using this key to encrypt the traffic. You are trying to do the same symmetric encryption again on top of TLS, only that you are don't have a secure way to exchange the key you use. It does not get more secure this way. | |
| May 2, 2017 at 15:55 | answer | added | LvB | timeline score: 2 | |
| May 2, 2017 at 15:38 | review | First posts | |||
| May 2, 2017 at 17:30 | |||||
| May 2, 2017 at 15:36 | history | edited | peter | CC BY-SA 3.0 |
edited title
|
| May 2, 2017 at 15:29 | history | asked | peter | CC BY-SA 3.0 |