View Issue Details

IDProjectCategoryView StatusLast Update
0000592Main CAcert WebsiteAudit issuespublic2014-09-18 19:32
Reporterhomer Assigned To 
PriorityurgentSeveritycrashReproducibilityalways
Status confirmedResolutionopen 
PlatformMain CAcert WebsiteOSN/A 
Summary0000592: 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.
TagsNo tags attached.
Reviewed by
Test Instructions

Relationships

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 closedSourcerer 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 

Activities

homer

2008-08-12 15:08

reporter   ~0001137

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

iang

2008-08-12 15:48

developer   ~0001138

Last edited: 2008-09-05 15:51

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.

iang

2008-08-12 15:53

developer   ~0001139

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

iang

2008-09-05 15:52

developer   ~0001153

Last edited: 2008-09-05 15:52

See blog post http://blog.cacert.org/2008/09/328.html Bug 2 for more.

ph3

2008-10-14 11:12

reporter   ~0001232

@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)

iang

2008-10-14 12:42

developer   ~0001234

@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...

ph3

2008-10-14 14:40

reporter   ~0001236

@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;
 	}
patch (1,035 bytes)   

2009-05-17 14:48

 

validatealt.php (1,569 bytes)

Daniel Black

2009-05-17 14:50

reporter   ~0001409

Last edited: 2009-05-17 14:52

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

 

validatealt2.php (1,919 bytes)

edgarwahn

2009-09-30 12:43

developer   ~0001486

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.

Daniel Black

2009-09-30 13:01

reporter   ~0001487

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.

edgarwahn

2009-09-30 13:25

developer   ~0001488

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.

iang

2009-09-30 13:26

developer   ~0001489

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.

aderouineau

2010-04-18 23:06

reporter   ~0001576

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.

Sourcerer

2010-07-28 11:57

administrator   ~0001606

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?

Issue History

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