Summary: It is essential to provide a configuration option in the operating system to: 1. never trust invalid certificates, and 2. to not prompt to trust them. Steps to reproduce: 1. Install OS X on an Apple laptop. 2. Configure Mail.app (for example) to connect over SSL to your mail server. Prepare a draft email with sensitive information about the iPhone 8 or whatever. 3. Go treat yourself to a hotel visit. 4. Connect to the hotel Wifi SSID but do not pay or authenticate yet. 5. The dialog appears: "Verify Certificate. Mail can't verify the identity of "your.secure.server.apple.com". The certificate for this server is invalid. You might be connecting to a server that is pretending to be "foo" which could put your confidential information at risk. Do you want to connect to the server anyway?" 6. Accidentally click "Continue" 7. Send your sensitive email. Remarks: Networks implemented with a walled garden, or a malicious fake network returning false DNS responses will both behave in the same way. DNS responses and any TCP responses are liable to be completely fake data. In the case of the hotel network, until authentication every IP address and HTTP response probably resolves to the Wifi login service. Likewise, outbound SSL connections will return some sort of fake response, including an invalid certificate, until you establish the hotel's Wifi service. In the alternate case of a malicious Wifi network, only a specified subset of responses need to be fabricated, but clearly these would be tailored by the attacker to steal or modify private data. The certificate mechanism is the last line of defense for the end user against such a Man-in-the-middle attack. To override the default trust with a quick click of a "Connect" button robs the average user of a reasonable level of protection from the operating system. Further, the text "DO YOU WANT TO CONNECT TO THE SERVER ANYWAY?" and the placement of the "Connect" button make it seem like a default option and for the user who TL;DR the last sentence actually reads like a goading suggestion. A Google search of the error message confirms, most users are concerned with clicking through the dialog rather than their data privacy. Expected Results: 1. For practical purposes, if the Mail.app program is configured with SSL, then it does not actually have a connection to the mail server. This is evident in the certificate mismatch itself. 2. User actions with high security implications should default to secure options and should require a positive and unequivocal input for setting any dangerous configuration. 3. A maximally secure, but still functional, setting should be possible. Actual Results: 1. The Mail.app program connects to the invalid server once the user clicks "Connect", or inadvertently types the Enter key at the same time the dialog pops up. 2. In the case of a malicious Wifi network, the sensitive email has now been sent to the Man-in-the-middle attacker. 3. It is not even possible to configure OS X to simply reject invalid certificates outright. Proposed changes: 1. Change the dialog box so it is much more difficult to ACCIDENTALLY accept the invalid certificate; 2. Provide a global configuration option for the system administrator, that trusts only a whitelist of mismatched certificates, and silently rejects any other invalid SSL connection attempt. Timeline: April, 2014 - Disclosed to Apple via Bug Reporter #16505012 January 27, 2015 - attempt to request contact at Apple via FullDisclosure. Result below. January 29, 2015 - Reminded Apple to review, and advance notice of public disclosure.