111–120 of 163 posts
Earlier quoted context omitted.
http://revealingerrors.com/akamai_ssl
The post does not explain why Akamai's cert is being used. If bing over SSL were working correctly in the past---which I believe to be true---and given that Bing were using Akamai in the past, why the problem now?
Looks like it might be related to the reddit DDOS: http://www.reddit.com/r/redditTraffic/comments/1coaer/201304...
TL;DR: bing SSL certificate is wrong. https://bing.com : subject=/CN=*.bing.com https://www.bing.com : subject=/C=US/O=Akamai Technologies, Inc./CN=a248.e.akamai.net
TL;DR: Bing doesn't support SSL on www.bing.com and has never publicized it as a supported feature. The submitter had to manually type https://www.bing.com into the address bar to generate this 'error'. Bing does support SSL on ssl.bing.com and publishes various links on that sub-domain, such as https://ssl.bing.com/webmaster/home/mysites The fact that the https://www.bing.com redirects to the HTTP version should be…
Or use HTTPS Everywhere. Personally, I'd also like it if in future, web browsers would try HTTPS first and HTTP second.
Earlier quoted context omitted.
Why not use the word "summary"?
I think it's the same reason people write "lol" instead of "hahaha" even though they are not actually laughing out loud. It sounds like internet speek, it's cooler and more 1337.
Interesting article on a related topic: http://www.bbc.co.uk/news/magazine-21956748
Earlier quoted context omitted.
TL;DR: Bing doesn't support SSL on www.bing.com and has never publicized it as a supported feature. The submitter had to manually type https://www.bing.com into the address bar to generate this 'error'. Bing does support SSL on ssl.bing.com and publishes various links on that sub-domain, such as https://ssl.bing.com/webmaster/home/mysites The fact that the https://www.bing.com redirects to the HTTP version should be…
>TL;DR: Bing doesn't support SSL on www.bing.com and has never publicized it as a supported feature. The submitter had to manually type https://www.bing.com into the address bar to generate this 'error'. Or use HTTPS Everywhere. Personally, I'd also like it if in future, web browsers would try HTTPS first and HTTP second.
Earlier quoted context omitted.
Working in information security, I see this far, far too often in support tickets from employees who are unable to get to a site because our proxy is blocking misconfigured certificates. Usually we like to reach out to the owner of the site and have them update their configuration, and it gets quite frustrating when we find an unresponsive organization. Having to bypass cert checking for a site on our end is a huge s…
> There's no reason to send a page to your users over HTTPS if they can't trust the certificate. There can be. HTTPS still gives you encryption over the wire. It still protects against a passive eavesdropper, like a casual packet sniffer on a public wi-fi network. The whole certificate deal protects against a Mallory with power to intercept and spoof messages. Of course nobody on the public internet can be sure there…
Training users to click through messages that are completely valid warnings is just shitty behavior.
Earlier quoted context omitted.
>TL;DR: Bing doesn't support SSL on www.bing.com and has never publicized it as a supported feature. The submitter had to manually type https://www.bing.com into the address bar to generate this 'error'. Or use HTTPS Everywhere. Personally, I'd also like it if in future, web browsers would try HTTPS first and HTTP second.
[deleted]
Earlier quoted context omitted.
> There's no reason to send a page to your users over HTTPS if they can't trust the certificate. There can be. HTTPS still gives you encryption over the wire. It still protects against a passive eavesdropper, like a casual packet sniffer on a public wi-fi network. The whole certificate deal protects against a Mallory with power to intercept and spoof messages. Of course nobody on the public internet can be sure there…
Right. MitM attacks and variants are a proper subset of the mischief that can be achieved with an unsecured connection. Among other things, it's routine that people (hi!) use self-signed certs for personal or temporary TLS sites. I'd be very annoyed to pass a basic-auth-protected https git url to someone for quick-and-mostly-secure read-only access and have their access be denied by a local proxy...
Untrusted certificate chains is a valid security risk. If it annoys you that users are blocked from viewing your site because you haven't gone through the established and accepted practice of actually completing the SSL trust chain, that's not the local proxy's fault.
My number one concern is the integrity and security of my company's data. Your personal or temporary TLS site is much lower down that list, especially if you're serving up untrusted certificates and expecting that users will completely ignore the warnings that try to keep them from falling victim to the kinds of attacks SSL is meant to avoid.
Earlier quoted context omitted.
Right. MitM attacks and variants are a proper subset of the mischief that can be achieved with an unsecured connection. Among other things, it's routine that people (hi!) use self-signed certs for personal or temporary TLS sites. I'd be very annoyed to pass a basic-auth-protected https git url to someone for quick-and-mostly-secure read-only access and have their access be denied by a local proxy...
>I'd be very annoyed to... have their access be denied by a local proxy Untrusted certificate chains is a valid security risk. If it annoys you that users are blocked from viewing your site because you haven't gone through the established and accepted practice of actually completing the SSL trust chain, that's not the local proxy's fault. My number one concern is the integrity and security of my company's data. Your…
In the example in question (which frankly isn't very interesting, I can come up with hundreds of scenarios like this) I have a git archive I need to share with someone on an ad-hoc basis. For whatever reason, I'd like to do it securely, so it needs authentication and encryption and shouldn't go on anyone else's site. So the obvious solution is to throw it up on a static webserver somewhere and use TLS (or use ssh, of course, but that's subject to exactly the same root-of-trust problem as a self-signed cert -- surely you disallow outbound ssh access too, right? right?).
Your fantasy world wants to pretend requirements like this don't exist, and that you can simply refuse to support this kind of transfer via fiat. But it's not the real world. In the real world, this is what people have to do. Unless you break their systems, in which case they'll work around your silly rules in even less secure ways.