CouchDB 中的基本 HTTP 身份验证对于跨 EC2 区域的复制来说是否足够安全？
我可以理解，在同一句话中看到“基本身份验证”和“足够安全”很像阅读“不带降落伞跳伞仍然安全吗？”，所以我会尽力澄清我的意思。
从我在网上看到的情况来看，人们通常将基本 HTTP 身份验证描述为不安全，因为凭据以纯文本形式从客户端传递到服务器；这使得您的凭据很容易被网络配置中的恶意人员或中间人嗅探，其中您的流量可能会通过不受信任的访问点（例如咖啡店的开放 AP）。
为了确保您和服务器之间的对话安全，解决方案通常是使用基于 SSL 的连接，其中您的凭据可能以纯文本形式发送，但您和服务器之间的通信通道本身是安全的。
那么，关于我的问题...
在将一个 CouchDB 实例从一个区域（例如美国西部）的 EC2 实例复制到另一个区域（例如新加坡）的另一个 CouchDB 实例的情况下，网络流量将穿过以下路径：我认为“可信”的骨干服务器。
鉴于（假设我没有复制高度敏感的数据）任何人/每个人都会认为 CouchDB 复制的基本 HTTP 身份验证足够安全吗？
如果不是，请澄清我在这里缺少哪些场景会导致此设置不可接受。我确实理解这对于敏感数据来说是不合适的，我只是想更好地了解通过相对可信的网络复制的非敏感数据的来龙去脉。
I can appreciate that seeing "basic auth" and "safe enough" in the same sentence is a lot like reading "Is parachuting without a parachute still safe?", so I'll do my best to clarify what I am getting at.
From what I've seen online, people typically describe basic HTTP auth as being unsecured due to the credentials being passed in plain text from the client to the server; this leaves you open to having your credentials sniffed by a nefarious person or man-in-the-middle in a network configuration where your traffic may be passing through an untrusted point of access (e.g. an open AP at a coffee shop).
To keep the conversation between you and the server secure, the solution is to typically use an SSL-based connection, where your credentials might be sent in plain text, but the communication channel between you and the server is itself secured.
So, onto my question...
In the situation of replicating one CouchDB instance from an EC2 instance in one region (e.g. us-west) to another CouchDB instance in another region (e.g. singapore) the network traffic will be traveling across a path of what I would consider "trusted" backbone servers.
Given that (assuming I am not replicating highly sensitive data) would anyone/everyone consider basic HTTP auth for CouchDB replication sufficiently secure?
If not, please clarify what scenarios I am missing here that would make this setup unacceptable. I do understand for sensitive data this is not appropriate, I just want to better understand the ins and outs for non-sensitive data replicated over a relatively-trusted network.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
鲍勃是对的，谨慎行事会更好，但我不同意。鲍勃在这种情况下可能是对的（请参阅下面的详细信息），但他的一般方法的问题在于它忽略了偏执的成本。它留下了“和平红利”的钱。我更喜欢布鲁斯·施奈尔的评估，即这是一种权衡。
简短回答
现在开始复制！不用担心 HTTPS。
最大的风险不是线路嗅探，而是您自己的人为错误，其次是软件错误，这可能会破坏或损坏您的数据。 制作一个复制品！。如果您要定期进行复制，请计划迁移到 HTTPS 或同等协议（SSH 隧道、stunnel、VPN）。
基本原理
HTTPS 对于 CouchDB 1.1 来说容易吗？它就像 HTTPS 一样简单，或者换句话说，不，这并不容易。
您必须制作 SSL 密钥对、购买证书或运行自己的证书颁发机构 - 当然，您不会愚蠢到自签名！从您的远程沙发上可以清楚地看到用户的散列密码！为了防止破解，您会实施双向 SSL 身份验证吗？ CouchDB 支持吗？也许您需要 VPN？您的密钥文件的安全性怎么样？不要将它们签入 Subversion！并且不要将它们捆绑到您的 EC2 AMI 中！这违背了目的。您必须将它们分开并保持安全。当您部署或从备份恢复时，请手动复制它们。另外，用密码保护它们，这样如果有人获取了这些文件，他们就无法窃取（或更糟糕的是，修改！）您的数据。当您启动 CouchDB 或复制时，必须手动输入密码才能进行复制。
简而言之，每个安全决策都有成本。
一个类似的问题是，“我应该在晚上锁上我的房子吗？这要看情况。您的个人资料显示您在图森，所以您知道某些社区是安全的，而另一些社区则不安全。是的，确实如此。始终锁上所有门总是更安全，但是您的时间和心理健康成本是多少？这个类比有点不成立，因为在最坏情况的安全准备上投入的时间比拧螺栓锁要多得多。
Amazon EC2 是一个中等安全的主要风险是针对常见错误的机会主义、广谱扫描。基本上，有组织的犯罪是扫描常见的 SSH 帐户和 Web 应用程序（例如 Wordpress），以便他们可以获取信用卡或其他数据库
。没有人特别关心你。 除非你是政府或有组织的犯罪分子的特别目标，或者是有资源和动机的人（嘿，这就是 CouchDB，这种情况就会发生！）效率低下担心妖怪。你的对手正在撒大网以获取最大的收获。没有人想用鱼叉捕鱼你。
我把它看成是高中积分：测量曲线下的面积。时间向右（x 轴）。危险行为上升（y 轴）。当你做一些有风险的事情时，你节省了时间和精力，但图表会上升。当你以安全的方式做某事时，会花费时间和精力，但图表会向下移动。您的目标是最小化曲线下的长期面积，但每个决定都是根据具体情况而定的。大多数美国人每天都乘坐汽车：这是美国人生活中最危险的行为。我们直观地理解风险与收益的权衡。互联网上的活动是相同的。
Bob is right, it is better to err on the side of caution, but I disagree. Bob could be right in this case (see details below), but the problem with his general approach is that it ignores the cost of paranoia. It leaves "peace dividend" money on the table. I prefer Bruce Schneier's assessment that it is a trade-off.
Short answer
Start replicating now! Do not worry about HTTPS.
The greatest risk is not wire sniffing, but your own human error, followed by software bugs, which could destroy or corrupt your data. Make a replica!. If you will replicate regularly, plan to move to HTTPS or something equivalent (SSH tunnel, stunnel, VPN).
Rationale
Is HTTPS is easy with CouchDB 1.1? It is as easy as HTTPS can possibly be, or in other words, no, it is not easy.
You have to make an SSL key pair, purchase a certificate or run your own certificate authority—you're not foolish enough to self-sign, of course! The user's hashed password is plainly visible from your remote couch! To protect against cracking, will you implement bi-directional SSL authentication? Does CouchDB support that? Maybe you need a VPN instead? What about the security of your key files? Don't check them into Subversion! And don't bundle them into your EC2 AMI! That defeats the purpose. You have to keep them separate and safe. When you deploy or restore from backup, copy them manually. Also, password-protect them so if somebody gets the files, they can't steal (or worse, modify!) your data. When you start CouchDB or replicate, you must manually input the password before replication will work.
In a nutshell, every security decision has a cost.
A similar question is, "should I lock my house at night? It depends. Your profile says you are in Tuscon, so you know that some neighborhoods are safe, while others are not. Yes, it is always safer to always lock all of your doors all of the time. But what is the cost to your time and mental health? The analogy breaks down a bit because time invested in worst-case security preparedness is much greater than twisting a bolt lock.
Amazon EC2 is a moderately safe neighborhood. The major risks are opportunistic, broad-spectrum scans for common errors. Basically, organized crime is scanning for common SSH accounts and web apps like Wordpress, so they can a credit card or other database.
You are a small fish in a gigantic ocean. Nobody cares about you specifically. Unless you are specifically targeted by a government or organized crime, or somebody with resources and motivation (hey, it's CouchDB—that happens!), then it's inefficient to worry about the boogeyman. Your adversaries are casting broad nets to get the biggest catch. Nobody is trying to spear-fish you.
I look at it like high-school integral calculus: measuring the area under the curve. Time goes to the right (x-axis). Risky behavior goes up (y-axis). When you do something risky you saved time and effort, but the the graph spikes upward. When you do something the safe way, it costs time and effort, but the graph moves down. Your goal is to minimize the long-term area under the curve, but each decision is case-by-case. Every day, most Americans ride in automobiles: the single most risky behavior in American life. We intuitively understand the risk-benefit trade-off. Activity on the Internet is the same.
正如您所暗示的，没有传输层安全的基本身份验证是 100% 不安全的。 EC2 上任何可以嗅探您的数据包的人都可以看到您的密码。假设没有人可以是一个错误。
在 CouchDB 1.1 中，您可以启用本机 SSL。在早期版本中，使用 stunnel。添加 SSL/TLS 保护非常简单，没有理由不这样做。
As you imply, basic authentication without transport layer security is 100% insecure. Anyone on EC2 that can sniff your packets can see your password. Assuming that no one can is a mistake.
In CouchDB 1.1, you can enable native SSL. In earlier version, use stunnel. Adding SSL/TLS protection is so simple that there's really no excuse not to.
我刚刚从亚马逊找到了这个声明，它可能会帮助任何试图了解 EC2 上数据包嗅探风险的人。
http://aws.amazon.com/articles/1697
I just found this statement from Amazon which may help anyone trying to understand the risk of packet sniffing on EC2.
http://aws.amazon.com/articles/1697