惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

T
Tenable Blog
博客园_首页
Vercel News
Vercel News
WordPress大学
WordPress大学
美团技术团队
G
Google Developers Blog
大猫的无限游戏
大猫的无限游戏
小众软件
小众软件
Y
Y Combinator Blog
博客园 - 【当耐特】
量子位
酷 壳 – CoolShell
酷 壳 – CoolShell
The Cloudflare Blog
T
The Blog of Author Tim Ferriss
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Google DeepMind News
Google DeepMind News
云风的 BLOG
云风的 BLOG
腾讯CDC
M
MIT News - Artificial intelligence
爱范儿
爱范儿
Recent Announcements
Recent Announcements
雷峰网
雷峰网
Last Week in AI
Last Week in AI
宝玉的分享
宝玉的分享
The Register - Security
The Register - Security
Jina AI
Jina AI
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Hugging Face - Blog
Hugging Face - Blog
P
Privacy & Cybersecurity Law Blog
Recorded Future
Recorded Future
Help Net Security
Help Net Security
N
News and Events Feed by Topic
博客园 - Franky
P
Proofpoint News Feed
L
LINUX DO - 热门话题
S
SegmentFault 最新的问题
The GitHub Blog
The GitHub Blog
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
月光博客
月光博客
D
Docker
Google DeepMind News
Google DeepMind News
有赞技术团队
有赞技术团队
IT之家
IT之家
Security Latest
Security Latest
L
LangChain Blog
V
V2EX
阮一峰的网络日志
阮一峰的网络日志
J
Java Code Geeks

Henri Sivonen’s pages

Parin vuoden tutkimattomuus crates.io: Rust Package Registry Asiakirjatonta toimintaa It’s not wrong that "🤦🏼‍♂️".length == 7 Koulutartuntojen tilastointimenettely Perusteasiakirjoja hallussapitämättä ikärajoitettu Asiantuntijat ja nukkuva vallan vahtikoira Koronapassilausunto Suppealla tietopohjalla ohimeneväksi väitetty Text Encoding Menu in 2021 The Text Encoding Submenu Is Gone An HTML5 Conformance Checker Not Part of the Technology Stack Browser Technology Stack Bogo-XML Declaration Returns to Gecko A Look at Encoding Detection and Encoding Menu Telemetry from Firefox 86 Why Supporting Unlabeled UTF-8 in HTML on the Web Would Be Problematic Rust Target Names Aren’t Passed to LLVM Toimintamalli Activating Browser Modes with Doctype Johtopäätöksiä mallin rakenteesta Tehtävänmäärittelyä kirjoittamatta ja kuolemia laskematta laumasuojamallinnettu Character Encoding Menu in 2014 Erillissuosituksen tarpeettomuudesta yleissuosituksen poikkeukseksi? STM:n maskiaikajana Rust 2021 Oma-aloitteisesti mallinnettu Kokopinovaatimuksin kilpailutettu chardetng: A More Compact Character Encoding Detector for the Legacy Web Varauksia paisutellen tiedotettu Perusteasiakirjoitta tiedotettu Always Use UTF-8 & Always Label Your HTML Saying So IME Smoke Testing The Validator.nu HTML Parser About the Hiragino Fonts with CSS It’s Time to Stop Adding New Features for Non-Unicode Execution Encodings in C++ Rust 2020 The Last of the Parsing Quirks About about:blank Rust 2019 a Web-Compatible Character Encoding Library in Rust How I Wrote a Modern C++ Library in Rust Using cargo-fuzz to Transfer Code Review of Simple Safe Code to Complex Code that Uses unsafe A Rust Crate that Also Quacks Like a Modern C++ Library #Rust2018 No Namespaces in JSON, Please A Lecture about HTML5 Julkisesti luotettu varmenne ikidomainille TLS:ää (SSL:ää) varten -webkit-HTML5 Lists in Attribute Values The Sad Story of PNG Gamma “Correction” If You Want Software Freedom on Phones, You Should Work on Firefox OS, Custom Hardware and Web App Self-Hostablility HTML5 Parser Improvements ARIA in HTML5 Integration: Document Conformance (Draft, Take Two) Schema.org and Pre-Existing Communities Lowering memory requirements by replacing Schematron HTML5 Parsing in Gecko: A Build Introducing SAX Tree NVDL Support in Validator.nu HOWTO Avoid Being Called a Bozo When Producing XML An Unofficial Q&A about the Discontinuation of the XHTML2 WG Thoughts on HTML5 Becoming a W3C Recommendation Four Finnish Banks Training Users to Give Banking Credentials to Another Site Unimpressed by Leopard Sergeant Semantics The Content Sink Inheritance Diagram – 2006-06-30 What is EME? About Points and Pixels as Units The Performance Cost of the HTML Tree Builder Social Media Impression Management The spacer Element Is Gone Openmind 2006 Performance Mistake XHTML and Mobile Devices WebM-Enabled Browser Usage Share Exceeds H.264-Enabled Browser Usage Share on Desktop (in StatCounter Numbers) HTML5 Parser-Based View Source Syntax Highlighting Vendor Prefixes Are Hurting the Web Accept-Charset Is No More Dualroids Writing Structural Stylable Document in Mozilla Editor ISO-8859-15 on haitallinen Hourglass The Scientific Method According to Hixie Maemo Source Code Karpelan lukkovertaus ontuu Digitaalisesta arkistoinnista ARIA in HTML5 Integration: Document Conformance (Draft) XHTML—What’s the Point? (Draft, incomplete) Mac OS X Browser Comparison HOWTO Spot a Wannabe Web Standards Advocate An Idea About Intermediate Language Trees and Web UI Generation Bureaucracy Meets the Web Europe Day HOWTO Establish a 100% Literacy Rate What to Do with All These Photos? Charmod Norm Checking Validator Web Service Interface Ideas DTDs Don’t Work on the Web EFFI’s Day in Court Speaking at XTech
Thoughts on Using SSL/TLS Certificates as the Solution to Phishing
Henri Sivonen · 2011-12-22 · via Henri Sivonen’s pages

Gerv has written a document called Staying Safe From Phishing With Firefox and a companion discussion document. Since he’s soliciting feedback, I’ll play devil’s advocate for a moment.

Gerv’s solution relies on conditioning the users to observe the SSL/TLS lock icon and, hence, to use the end point identity certifying aspect of SSL/TLS. There are some problems with this.

SSL/TLS certificates are supposed to help identify DNS spoofing. However, it happens that VeriSign is both a major DNS operator and a major CA. In theory, this situation is totally corrupt, because VeriSign could manipulate and DNS and issue fraudulent certificates to cover it up.

It turns out the situation with VeriSign is problematic in practice, too. As far as IDN spoofing goes, the TLD without proper human vetting against obviously misleading domains has been the .com TLD—the TLD managed by VeriSign. On the other hand, VeriSign’s certification business has reportedly issued certificates that human vetting would have shown were obviously intended for fraudulent purposes.

Why should anyone believe VeriSign won’t certify IDN spoofs? VeriSign has a serious conflict of interest here. CAs and domain registrars are not paid by society for keeping the Internet clean. Instead, they get money from issuing certificates and domain names. In fact, many .com registrars offer services that are obviously designed to capitalize on cybersquatting.

IANAL, but it seems to me the American legal system is in part to blame. The common carrier defense says that a common carrier cannot be held responsible for the content flowing through their systems as long as they let everything pass. If the carrier censored something (no matter how obviously illegal), they would be considered to exercise editorial control and could be held responsible for illegal content they do not happen to censor. By same token, if a domain registrar tried to screen out fraudulent domain names but did not succeed 100%, I suppose a lawyer representing a phishing victim might sue the registrar. I do not know if this is true, but I would not be surprised if the .com registrars were preparing an “oh we don’t screen anything” defense.

Gerv mentions the possibility of revoking certificates after the fact. However, in my copy of Firefox, the CRL view is empty. It seems to me Firefox is not checking any CRLs by default. And if it did, the CRL would be a single point of failure in the network.

Of course, even if VeriSign was deemed unworthy of trust, Mozilla couldn’t distrust VeriSign by default, because that would be a bad usability move. VeriSign, thanks to its first-mover advantage, has positioned itself above scrutiny. Anyone shipping SSL/TLS-enabled software has to trust VeriSign by default in order to avoid annoying dialogs.

Looking at the situation from another angle, it is unfair that anyone who does not want to look suspicious has to pay a third party company for protection. One could argue that the price of protection is peanuts for banks, but there are other considerations as well. Consider the Training Portal of The Finnish Defence Forces for instance. The certificate for that site is from the Finnish Population Register Centre—a government CA. A Finnish government site is certified by the Finnish government CA. Makes sense, right? Except no browser trusts the Finnish Population Register Centre by default and a warning dialog has to be explained away. Why should the Finnish Defence Forces have to pay an American company for protection in order to make the dialog go away?

This is not a matter of which CA is doing a better job vetting their clients. I argue that if a site has a certificate signed by the Finnish Population Register Centre, the probability of that site being what it appears to be is higher than for a site whose certificate is signed by VeriSign. So should Mozilla trust the Finnish Population Register Centre by default? I predict that some Americans who think that corporations are good and governments are evil would totally freak out if Mozilla was trusting a foreign government by default. (And that’s even a government that keeps a Big Brother Population Register so that a murky party-manipulated voter registration scheme is not needed and a list of eligible voters can be generated from a database at any time. Can you see the black helicopters already?)

There are also university CAs (eg. the CAs of University of Helsinki and Helsinki University of Technology) that seem to be doing a good job at screening who they give certificates to. Should Mozilla trust all the universities on the planet? If not, users will see annoying dialogs and be conditioned to accept certificates that cannot be verified using the default root certificates.

This introduces a real practical problem. It is relatively common that someone wants to use the encryption aspect and is willing to take a risk in the initial handshake in order to avoid dealing with a big money CA. I think I have dismissed four or five warning dialogs related to unverified certificates during the past week. If end users become accustomed to dismissing such dialogues without thinking, the identity-certifying aspect of SSL/TLS, which is important when avoiding phishing, is diluted. Still, I am not willing to blame those who refuse to pay big money CAs for protection. I have set up a snake oil CA myself, study at a university that has its own CA and am a member of two societies that run their own CAs.