Timeline for Mitigating SSL bypassing on iOS
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 16, 2015 at 3:00 | comment | added | Steffen Ullrich | @fjw: Using the kill switch is covered by "...no man-in-the-middle can read the data unless the owner of the device explicitly made this possible by changing your application ...". The main point is that the owner is in control of the device and all the data which are stored on it or pass through it and not the developer of the application. | |
| Sep 16, 2015 at 0:53 | comment | added | thomasrutter | Steffen, either you or I have misunderstood something here. A device with SSL Kill Switch has disabled certificate validation. This specifically does enable man-in-the-middle attacks. The transport is not secure under this circumstance. Your points about sending data to a device outside your control are still valid and good advice as are these points about no tamper detection being foolproof, just not the points about the transport still being secure. | |
| Sep 15, 2015 at 12:58 | comment | added | Neil Smithline | As none of those methods are foolproof @FlorinCoada, you must still think of the client as under the user's control and implement thusly. | |
| Sep 15, 2015 at 12:41 | comment | added | sir_k | @mohsinkhan You can always look at doing some binary protection for your application to prevent people from ripping it apart. That can be extended to do multiple things, such as jailbreak detection, protect against reverse engineering, etc. | |
| Sep 15, 2015 at 11:12 | comment | added | Mohsin Khan | so it means I must assume that my application will be ripped apart by someone and nothing should be sent to a user that i don't want to disclose, I am thinking about it this way, thanks | |
| Sep 15, 2015 at 11:04 | history | answered | Steffen Ullrich | CC BY-SA 3.0 |