View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000592 | Main CAcert Website | Audit issues | public | 2008-08-12 15:04 | 2014-09-18 19:32 |
| Reporter | homer | Assigned To | |||
| Priority | urgent | Severity | crash | Reproducibility | always |
| Status | confirmed | Resolution | open | ||
| Platform | Main CAcert Website | OS | N/A | OS Version | stable |
| Summary | 0000592: The domain name checking have to be improved to be auditable | ||||
| Description | The domain name checking have to be improved to be auditable. We need to harden the domain name checking as it is somewhat prone to man in the middle attacks. Technical or Management actions have to be taken. | ||||
| Tags | No tags attached. | ||||
| Reviewed by | |||||
| Test Instructions | |||||
| related to | 0000325 | closed | Adding the ability for CAcert admins to blacklist domain names from being verified | |
| related to | 0000289 | closed | Exploiting whois and the add domain function | |
| related to | 0000522 | closed | DNS A record required to verify domain ownership | |
| related to | 0000436 | closed | Sourcerer | Any live SMTP call stage of domain email before domain email checking |
| related to | 0000223 | confirmed | Auditor Interface | |
| related to | 0000826 | new | Auditing features for fighting abuse of CAcert systems in regard of adding domain/email addresses |
|
|
A possible solution would be to have a manual administrative action on the domain name automatically registered to be issued with class3 certificates. So the automatic registration for domain name would be only class1 cert eligible. We could ask a small donation for the extra work. Else we need to harden the technical process |
|
|
Another possibility: add a string to the domain registry information that means "CAcert is authorised to issue certs on this domain." (The string itself could be shorter, like CAcert-auth.) For example, do this: whois iang.org | grep CAcert. Then, the owner will have shown control over legal/responsible issues. This trumps the technical DNS or email probe procedures because they are both technically subvertible. The appearance of the appropriate string can be taken to mean authorisation to CAcert to issue certs. Weakness 1: This won't address what happens when a Member steals a domain from another Member ... but that we can deal with internally: Arbitration to kick some butt. Weakness 2: some domain registries aren't visible. For that we would fall back to DNS or HTML change. Combined together, domain registry string plus email probe would probably be good. |
|
|
For DRC, see https://financialcryptography.com/drc/browser.php . click on the "pingtest" one. These criteria are issues: A.2.h: at the minimum, the domain is only checked when added, not when the cert is issued. A.2.i: nope. A.2.q: nope |
|
|
See blog post http://blog.cacert.org/2008/09/328.html Bug 2 for more. |
|
|
@homer: > We could ask a small donation for the extra work. verifying the domain is one of the basic functions. if you relay on a donation I think it will make CAcert less attractive to users. @iang: involving the NICs isn't good as most people can't change the entries by there self or want to change something there for an organization like CAcert. I suggest another way: you can ask for a DNS change: adding a TXT or A record for 'cacert-auth.bla.tld' with a value given to the user (a transaction ID or something similar, not something static) |
|
|
@ph3: Yes, many people can't change the registry. Likewise, many people can't change the DNS. Many can't change the website delivery (headers, meta, files, HTML). Somewhere else (not sure where) all three methods are proposed, to be implemented in parallel, so the user has a choice, and some higher possibility of getting a hit. If we can figure out other methods, we could propose them as well. The net is a messy place... |
|
|
@iang: there are more people that can change there DNS zone than change the registry entries. I agree with you that a HTML meta tag would also be a a good way to do that, but for example in my case there are not necessary any webserver for that domain. some are only used for other services. I also agree with you that the best way is to provide multiple ways to verify. |
|
2009-05-17 14:47
|
patch (1,035 bytes)
diff --git a/includes/account.php b/includes/account.php
index 9daa2c9..1301bef 100644
--- a/includes/account.php
+++ b/includes/account.php
@@ -545,7 +545,9 @@
sendmail($authaddy, "[CAcert.org] "._("Email Probe"), $body, "support@cacert.org", "", "", "CAcert Support");
showheader(_("My CAcert.org Account!"));
+ $domain = $_SESSION['_config']['domain'];
printf(_("The domain '%s' has been added to the system, however before any certificates for this can be issued you need to open the link in a browser that has been sent to your email address."), $_SESSION['_config']['domain']);
+ printf(_("\nAlternately place the following string '%s' as a TXT DNS entry under the domain '%s'. Or in a file accessable at http://%s/cacert.txt, https://%s/cacert.txt, http://www.%s/cacert.txt or https://www.%s/cacert.txt. Or place the string in the whois database associated with the domain. These will be checked hourly for the next 2 days."), sha1($hash),$domain, $domain, $domain, $domain, $domain);
showfooter();
exit;
}
|
|
2009-05-17 14:48
|
|
|
|
Ok - it doesn't handle combining multiple options but it does provide options other than SMTP. validatealt.php as a hourly cron job. Expiry is already handled. Could add ftp if you really want too. This is a raw coding. I haven't actually tested it (haven't bothered to access or setup test system yet). |
|
2009-09-30 12:41
|
|
|
|
See validatealt2.php, some minor things fixed. matchTXT and matchWWW tested ok, little problems with testWHOIS, as DENIC does only offer an remarks field for handles and it seems that Holder and Admin-C are cut off the whois output. Therefore I can not test this, but I assume the mechanism is ok, as its all based on string comparison. But please have a look at $hash = sha1($hash); does this really make sense? You need to tell the user to put the sha1 of the hash code into his objects. |
|
|
if the you gave the user the straight hash they could just use that to enter it into the validation URL ..../verify.php?type=email&emailid=$emailid&hash= This would mean they could validate any domain without any proof at all. By hashing the hash (not the best mathematic code I admit) the user, regardless of gender, needs to put it in TXT/WWW/WHOIS so that validate script can verify it. note there is still a typo in validate.php:matchWWW httpsi isn't a new url type. |
|
|
Yes, there is still a protocol typo. For the hash: wouldn't it be better then, if we have separate hashes and fields in db for each auth method? Imagine we once need to tell how the user authenticated? Maybe we want more than one mechanism (i.e. at least 2 of 5) to match? If it is intended to use the same hash thats used for email, I agree to your explanation. |
|
|
Some notes, none of which have to be treated as important. Far better to get *something* anything up and going. Then we can tune it. a. Presumably the first word changes per user/instance like: $hash1 = sha1($username . time() . $domainname); b. By telling the user to put a unique string in, we confirm that we are talking to that user. If we told all users to put the same string in, then an attacker would know what we were looking for, without needing to intercept the user's communications. c. It is not really useful to put the entire sha1 result in, and could lead to errors in typing or so. I would suggest around 6 alphanumerics, and drop case. We could actually get away with less, but if users can cope with more than a 4 digit PIN code, it gives us more protection against stuff we haven't thought about as yet. 6 alpha numerics is a nice number from CAPTCHAs, also flight reservation numbers, car number plates, etc, d. Also, I would add a standard string as part of the advice. Something like CAcert. Or invent a name for the project. Then, when one user puts in the string, and forgets what it is, or he gets promoted, the confused sysadm can ask around for what that word is ... and recall or verify or fix or carry on. Something like CAcert-abc123. Or domboss-098zxy where DOMBOSS stands for "domain ownership & management - basic offered string system." Or whatever funny acronym people can come up with and is easy to google. DOM BOSS is easy to remember as domain boss, and boss is a word that easily works in other languages. e. Whatever the system is ... it should be more or less the same for email, DNS, whois, HTTP, etc. We want the same basic string to work in all places, so the code is simpler, the training & support is easier, etc. |
|
|
You guys should use ISC's method for their DNSSEC DLV (https://dlv.isc.org/). 1) The user requests to add the domain 2) CAcert server generates a cookie to be added as a TXT record for a certain sub-domain (or perhaps to the user's liking) 3) The user adds the TXT record to the DNS and waits until all slaves receive the update 3) CAcert server checks *ALL* nameservers of the domain for the TXT cookie. 4) If it's present on all of them, the verification passes. Anyone owning a domain has a direct or indirect way of changing the DNS records. I am against changing a WHOIS entry because that is public information. I'm also against using pre-defined account names for email verification. Giving an option of the different email addresses taken from WHOIS seems good however. |
|
|
I am interested in the threat-model. What does "man in the middle attacks" mean exactly? Which protocols/services are attacked, which not (DNS, WHOIS, SMTP, HTTPS)? Where is the attacker? Which timeframe does the attack have? Can you give an example/technical-analysis of such an attack? |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-08-12 15:04 | homer | New Issue | |
| 2008-08-12 15:04 | homer | Status | new => confirmed |
| 2008-08-12 15:08 | homer | Note Added: 0001137 | |
| 2008-08-12 15:08 | homer | Relationship added | related to 0000325 |
| 2008-08-12 15:09 | homer | Relationship added | related to 0000289 |
| 2008-08-12 15:09 | homer | Relationship added | related to 0000522 |
| 2008-08-12 15:09 | homer | Relationship added | related to 0000436 |
| 2008-08-12 15:48 | iang | Note Added: 0001138 | |
| 2008-08-12 15:53 | iang | Note Added: 0001139 | |
| 2008-09-05 15:51 | iang | Note Edited: 0001138 | |
| 2008-09-05 15:52 | iang | Note Added: 0001153 | |
| 2008-09-05 15:52 | iang | Note Edited: 0001153 | |
| 2008-10-14 11:12 | ph3 | Note Added: 0001232 | |
| 2008-10-14 12:42 | iang | Note Added: 0001234 | |
| 2008-10-14 14:40 | ph3 | Note Added: 0001236 | |
| 2009-05-17 14:47 | Daniel Black | File Added: patch | |
| 2009-05-17 14:48 | Daniel Black | File Added: validatealt.php | |
| 2009-05-17 14:50 | Daniel Black | Note Added: 0001409 | |
| 2009-05-17 14:52 | Daniel Black | Note Edited: 0001409 | |
| 2009-09-30 12:41 | edgarwahn | File Added: validatealt2.php | |
| 2009-09-30 12:43 | edgarwahn | Note Added: 0001486 | |
| 2009-09-30 13:01 | Daniel Black | Note Added: 0001487 | |
| 2009-09-30 13:25 | edgarwahn | Note Added: 0001488 | |
| 2009-09-30 13:26 | iang | Note Added: 0001489 | |
| 2010-04-18 23:06 | aderouineau | Note Added: 0001576 | |
| 2010-07-28 11:57 | Sourcerer | Note Added: 0001606 | |
| 2012-12-20 18:38 | Werner Dworak | Relationship added | related to 0000223 |
| 2013-07-20 08:40 | INOPIAE | Relationship added | related to 0000826 |
