Timeline for Passwords in plaintext?
Current License: CC BY-SA 3.0
9 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Sep 30, 2014 at 13:48 | vote | accept | marcomanzoni | ||
Sep 30, 2014 at 13:46 | comment | added | Iszi | @marcomanzoni Different apps and OS's handle invalid certificates differently. Most desktop web browsers and Operating Systems are pretty good about warning the user of invalid certificates. Other desktop applications may not be so reliable. Mobile platforms, especially at the app level, are hit or miss. When an app fails to warn a user that a server it is contacting has presented an untrustworthy certificate (i.e.: one not signed by a CA the app or device has been configured to trust), that represents a vulnerability in the app. | |
Sep 30, 2014 at 13:41 | comment | added | marcomanzoni | Yes @Iszi I'm quite new in this world of SSL, Proxies, Certificates and stuff like that, but the problem is that the App didn't ask to me about the SSL certificate. For example gmail asked to me if I want to trust the CA, Facebook.app completely rejects the connection, but this specific App that I'm testing simply accept the Certificate. Also why can I replicate the request from my computer using curl and skipping the Certificate Validation process? | |
Sep 30, 2014 at 13:34 | comment | added | Iszi | Sounds to me like @marcomanzoni isn't very familiar with SSL proxies, and therefore possibly hasn't configured their phone with the BurpSuite CA. Given that, one of two things has probably happened: 1.) User ignored SSL warnings provided by the app. 2.) App ignored untrustworthy SSL certificate and proceeded without presenting warning or error. The former is a common end-user issue. The latter is a security vulnerability in the app. | |
Sep 30, 2014 at 13:20 | comment | added | Philipp | Burp can't force the iPhone to accept its root CA. It would need to be installed manually. | |
Sep 30, 2014 at 13:17 | comment | added | marcomanzoni | Can you explain some details on how it works? So imagine I have an iPhone, a Mac with Burp running in proxy mode and a server called X. The iPhone now tries to establish a secure connection with X. The first stage of the handshake is intercepted by Burp that replies with his own certificate, so the iPhone will receive the proxy certificate instead of that of the server. The Burp's certificate is signed by Burp itself. Right? How can Burp force the iPhone to add himself to se CA list? And then? How the communication evolve? Thanks. | |
Sep 30, 2014 at 12:02 | comment | added | Philipp |
@Curious Burp would get the certificate warning in that case when it connects to the fake-gmail.com server on behalf of the client. Depending on how it is configured it could then abort the connection attempt.
|
|
Sep 30, 2014 at 11:59 | comment | added | Curious | Burp issues a certificate to the webserver itself? Isn't this dangerous? If attacker creates his own version of e-mail site, and lures user to login using say gmail password, will Burp issue the certificate to this phishing site? | |
Sep 30, 2014 at 10:43 | history | answered | Philipp | CC BY-SA 3.0 |