5 ms·
Safari can't verify the identity of the website "blog.easydns.org". The certificate for this website is invalid. You might be connecting to a website that is p
by rwg 13y ago
Safari can't verify the identity of the website "blog.easydns.org".
The certificate for this website is invalid. You might be connecting to a website that is pretending to be "blog.easydns.org", which could put your confidential information at risk. Would you like to connect to the website anyway?
- Karunamon 13y agoAs usual, misconfiguration causing scary warnings, useless to the end user, but the connection is still encrypted. I really wish we'd divorce the identity assurance part of PKI from the encryption part. I have no idea how it would be done, but.
- GauntletWizard 13y agoHTTPS Encryption is virtually useless without the identify verification part. Anyone can run a valid HTTPS server with a self-generated public key. Anyone could then place a MITM, and without the identity bit, you're just as compromised. If we had dropped the identity bit, every ISP would be running a MITM proxy, because they want control. Already, plenty of businesses enable poor hygiene by including transparent squid proxies that strip SSL.
- eliasmacpherson 13y agoCould you run your own CA?
- jakejake 13y agoYou can but you'd need to convince browser vendors to add your CA to their list of trusted CA's in order to get rid of the security warning.
- eliasmacpherson 13y agoCan you add a CA to firefox manually yourself? It looks like you can.
- akama 13y agoYou can, you can also add a CA to all operating systems as well.
- alcari 13y agoAdding a single root to locally installed copies of a web browser is only really useful for 2 things: testing an SSL configuration for development, and deploying your own CA to all computers on an intranet to so you can MITM their traffic without throwing up warnings. For a bit of fun, compare the warnings about a self-signed certificate in Firefox with those triggered by attempting to download a self-signed certificate with the CA:true bit set.
- eliasmacpherson 13y agoSo this single root ploy is what large companies do to MITM their employees at work, I assume. I'll have to investigate what you suggest I do for fun, because I haven't tinkered with these certs before. What flags do you pass to openssl? The certificates do specify the issuer though. So you could use a self run CA in the manual arrangement to verify that your connection isn't being MITM'd, assuming you don't lose control of your self run CA, or leak its private key. Correct me if I am wrong.
- jakejake 13y agoI know I've heard about this somewhere before, but it seems to me somewhat a hassle to setup MITM attacks if you already have admin access over all the machines. Just put a browser plugin that logs everything and lock down the machines to they can't be messed with by non-admins. Corporate employees are generally not allowed to admin their own machines or expect any privacy on them - so there's no point in hiding the fact that you log everything. If you're just trying to do a MITM for fun, though, there's nothing magical about the CA or cert. Once you configure the browser to trust a CA, then any cert signed with it will also be trusted by the browser. So if you are also running DNS on the network then you can re-route facebook.com or any domain to point to your own proxy server and serve up your fake cert. The user will see the nice green lock and everything. You could probably even name your CA and certs so that it looked pretty much exactly like a user would see it on the real facebook.com. The reason why this isn't happening all over the place is just because you need to already have root access to the machine to configure the trusted CAs. The ability to add a CA, I would probably consider that to be a fully owned machine.
- deleted 13y ago[deleted]
- mnutt 13y agoI was familiar with the reasons why using self-signed SSL didn't buy you anything, but hadn't really put together how it would completely weaken the whole ecosystem until now. "Oh, that's just Verizon MITMing me like always..."
- dTal 13y agoSelf-signed certificates are perfectly useful. Weaker security is still better than no security at all. For example, even unauthenticated, SSL protects you from log analysis after the fact. MITM is not the only threat model. If it's a personal page (say, a public-facing login to your NAS) you can always check the SSL fingerprint too. You don't have to remember the whole thing, just remember a few characters and check that they're right.
- mnutt 13y agoSure, but browsers are perfectly right to throw up a giant red warning that says "THIS IS NOT OK". Otherwise MITMing will become commonplace, and users won't care.
- dTal 13y agoThat's all well and good - my point was that this "self-signed certs are equivalent to no security at all" meme is both common and wrong. [EDIT] pdkl95 said what I was trying to say more eloquently and in more depth.
- boronine 13y agoDoes SSL not use a key exchange algorithm that ensures that a MITM proxy be useless?
- GauntletWizard 13y agoEven without the CA system, SSL (and TLS) is secure against _passive_ MITM attacks; That is, if the attacker cannot alter the data-stream. This is still reasonable for many simple links, but for internet, it is not. If you've got no verification of the opposite party, literally any computer could be on the other end. The key exchange mechanism is secure, certainly, but any computer can execute it. The attacker can even show you the real website just proxied through, but that's plenty enough to get your password or any other access that the attacker wants.
- mnw21cam 13y agoA "passive MITM" attack isn't MITM any more - it's just interception. MITM means that the man in the middle is able to control the data stream that both ends see.
- sokoloff 13y agoThe man in the middle can do the key exchange with you. (You seem to be assuming that you start with a connection that you know to be reaching the desired endpoint and that you can start the key exchange there. You can't. The MITM intercepts the initial connection and does the key exchange with you and then turns around and initiates a secure connection with the eventual endpoint. The endpoint sees valid, encrypted traffic and you see valid, encrypted traffic, but the MITM attacker has the full plaintext communication.) That's why you need the identity portion to be tied to the key exchange.
- pdkl95 13y agoThis is claimed every time the topic is brought up, and like the self-signed certificate scare-box in firefox, it does a significant amount of harm by forcing a choice between all or nothing. Which means many times, "nothing" will be chosen. Encryption without authentication is still incredibly useful, and something that we've NEEDED to have happen pretty much everywhere. Some of the benefits are: 1) The ccost of and attack is significantly larger, by protecting against passive eavesdropping. You can capture massive numbers of passwords trivially by simply logging and unencrypted stream, but full MitM requires more time, effort, and resources to accomplish. 2) MitM attacks can sometimes be detected, either at the time of the attack or in the future due to repeated opportunities for the attack discovered. A passive scanner is impossible to discover, in most cases. 3) Any use encourages a culture of encryption, so the people who ARE authenticating properly aren't as obvious. 4) The cost of moving from a self-signed key to one signed by a 3rd party is small ("get your cert signed"). This makes the upgrade path to full, properly authenticated crypto much smaller. All of these benefits are worthwhile, so please, stop encouraging the use of plaintext. The proper way of handling this is not to scare people away like Firefox currently does, but to encrypt everything automagically, so it works just like unencrypted HTTP, and only show the lock icon if full authentication has happened. That is, encrypting without auth should be used, but still presented to the user as a plain, unencrypted page.
- wtbob 13y agoEncryption without identity assurance really doesn't mean anything though--one might be a victim of a MITM attack. The issue is that XPKI is _really_ easy to get wrong, but there are alternatives.
- eliasmacpherson 13y agoWhat are the alternatives?
- wtbob 13y agoSPKI (http://en.wikipedia.org/wiki/Simple_public-key_infrastructure http://en.wikipedia.org/wiki/Simple_public-key_infrastructur...) is a great one. The guys behind it really thought hard about what a PKI should do, and what it can do, and what a relying party can actually rely on. Contrary to the Wikipedia page, there's a potential role for CAs. As an example, a CA could still sell a certificate authorising a key to, say, serve HTTPS data for the site foo.com; that key could then delegate authority for bar.foo.com, for www.foo.com and whatever else, without needing to go back cap-in-hand to the original CA. Among the cool things is that a CA trusted to vouch for people serving data in .com wouldn't necessarily be trusted to serve data for .co.uk. One might have CAs vouching for one's ownership of IP addresses. All of this was simple and straightforward, with a clean model (unlike the XPKI mess which conflates identity and authorisation), so of course it failed utterly.
- sparkie 13y agoMoxie introduced http://www.convergence.io/ http://www.convergence.io/ a while ago now (https://www.youtube.com/watch?v=8N4sb-SEpcg https://www.youtube.com/watch?v=8N4sb-SEpcg), which could offer significant advantages over the PKI if it became widely adopted. Although it's not an end-all solution to identity, it's a step in the right direction (using web-of-trust ideas).
- jedbrown 13y agoSo convergence.io is only available over HTTP, yet it offers the plugin for download. It seems an ironically bad practice to install security software over an untrusted connection. Meanwhile, https://convergence.io https://convergence.io yields a certificate for whispersystems.org and is in fact the https://whispersystems.org/ https://whispersystems.org/ main page (nothing to do with convergence.io). There appears to be no secure way to obtain Moxie's plugin (it is not available from mozilla.org, though a fork is available, based on this repo: https://github.com/mk-fg/convergence https://github.com/mk-fg/convergence). My understanding is that more recently, Moxie has been focusing on http://tack.io http://tack.io which offers improved security without overturning the CA model.
- sparkie 13y agoI'm not sure what would be more ironic, this, or it delivering a "secure" download over the protocol it intends to replace for not providing sufficient security guarantees. The other irony is that a self-signed cert is basically as good as any CA issued cert with Convergence on, if only there were a secure way to bootstrap it. Perhaps a secure way to obtain it would be to email Moxie using GPG and ask him to send you a copy, but as you suggest, it appears to be unmaintained aside from the fork anyway, so it isn't much more than research material for now. I hadn't heard of Tack yet, but that also appears to have a lack of activity.
- hyaline9 13y agoUnfortunately this project seems to have stalled; according to https://github.com/moxie0/Convergence https://github.com/moxie0/Convergence the code hasn't seen significant updates since 2011. A similar more up-to-date alternative is Perspectives: http://perspectives-project.org/ http://perspectives-project.org/
- csense 13y agoNamecoin
- deleted 13y ago[deleted]