DA's DKIM script needs to be updated

interfasys

Verified User
Joined
Oct 31, 2003
Messages
2,100
Location
Switzerland
In case you've missed it, some companies like Apple have implemented very weak keys for DKIM and it means that their email accounts can easily be spoofed.
http://www.kb.cert.org/vuls/id/268267

DA is doing OK at 768bit, but it's still crackable and it won't be long before it will be easily and cheaply crackable.

So I suggest DA gets updated scripts to generate 2048bits keys.
 
I think (and im not sure about this),

that edit the script:

Code:
/usr/local/directadmin/script/dkim_create.sh

(putting it in custom folder i presum) and changing line:

Code:
openssl genrsa -out ${PRIV_KEY} 768 2>&1

to

Code:
openssl genrsa -out ${PRIV_KEY} 2048 2>&1

Will do the trick.

Actually i dont know how apply the change to existent keys.

Regards
 
Correct, but all current keys need to be revoked and new keys need to be put in place, so a migration script has to be written.
 
Has anybody sent email about this to DirectAdmin support? If not, please let me know and I can send them a email about it.
 
Hello,

Thanks for the report.
I've changed the dkim_create.sh to create 2048-bit keys.. that was the easy part.
The issue is that these longer keys exceed the max record length in named, so I had to go into over-kill mode to get DA to support over-sized records.
http://www.directadmin.com/features.php?id=1387

Code:
instead of this, which will break the zone:
value TXT  "reallylongrecord"

it becomes:
value TXT  ( "really"
             "long"
             "record" )
But it still displayed as the "reallylongrecord" in DA.

The bulk of the pre-release binaries are uploaded now (Check for a "./directadmin o" compile date of October 29th or newer.
The FreeBSD 6 32-bit, FreeBSD 7 64-bit, and Debian 5 32-bit build boxes are currently down, so they don't have the pre-release binaries updated yet.

The only issue I can see right now.. is that the record is so long that it makes the tables very ... very ... wide.
For now, it's not a major issue as it "works".. but we'll need to decide what's best to make it look nicer:

1) Make the font size 4.. essentially un-readable, but can still copy/paste correctly.

2) wrap the lines.. readable but the copy/paste wouldn't be accurate with the newline characters beraking it up.

3) Show the ( "really"
"long"
"record" )
just like it shows in the domain.com.db file (leaning towards this one). To edit or add a long record, you'd need to use the single "reallylongrecord" format, so going back and forth would be annoying.

4) Chop the value, and have a ">>" or "Show More" button in the record's td.. and when the button is clicked, the full value is shown.

Suggestions/input welcome.

John
 
Hi John,

thanks for this but, actually change over 150+ domains manually would be a little hard dont you think?

Could you provide a "for each" statment that will work for each existing domain so we can run a single shot line code for update all existing?.

Regarding the table long, i think that with new-line would be good enough, i dont think anyone will go edit that line, i dont see (actually) no reason to do that.

Regards
 
Sure, fairly straight forward:
Code:
#!/bin/sh
for i in `cat /etc/virtual/domains`; do
{
    if [ -s /etc/virtual/$i/dkim.public.key ]; then
        rm -f /etc/virtual/$i/dkim.public.key
        rm -f /etc/virtual/$i/dkim.private.key
        /usr/local/directadmin/scripts/dkim_create.sh $i
    fi
};
done;
exit 0;
John
 
Thanks John.

Just to make it clear to everyone, this will NOT work if you dong grab pre-release or wait untill next release.

Regards
 
What is the best way to test the new keys? I've tried some testing sites, some come back with an error, some come back with this
 
This is the one I used that gave the :
============================================================
DomainKey result: none (no signature)
============================================================


============================================================
DKIM result: permerror (no key)
===========================================================
That said, I do not use my hosting domain's DNS on the server, so that could be why?


However, the signature is included (tested via gmail) although there's no mailed-by & signed-by
 
Last edited:
It seems to me, that this doesn't work
when you are using directadmin with powerdns (supermaster)
this dkim_create.sh only works when the ssl is 768 bit en not 2048 for powerdns

in the powerdns database the x._domainkey.domain.com is printed as example (one liner).

"v=DKIM1; k=rsa; p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAPDxtPX8N3QV6/8LuzmZXwYq+DbJixfjrq8MJfesaFhc2nQG5DnD4Ptmi2KYujVWUSTEJUzQLDGTS43Cy4RrsUhFKJH4onipcwp " "+7Dxghq3HEW3D22QyTKF7nPGldyzeywIDAQAB"

notice to quotes (If I remove the quote's including the space between the dkim is valid)
Has something to do with this:

Code:
instead of this, which will break the zone:
value TXT  "reallylongrecord"

it becomes:
value TXT  ( "really"
             "long"
             "record" )

Can we go back to the previous 768bit with the old TXT value settings?
We can change the dkim_create.sh back to 768 no problem. but the TXT record not i believe.

Any suggestions?
 
If powerdns is an external service it suppose that you copy/paste the key manually to them, am i right? If yes, paste the key just in one line ;)

Regards
 
Perhaps its possible to create something like this?

echo "action=rewrite&value=dkim&domain=${DOMAIN}&dns=yes&bit=768&txt=normal" >> /usr/local/directadmin/data/task.queue

where the variable bit = 768 or 2048 or higher
and the txt variable = normal or long (=reallylongrecord)
 
Last edited:
Back
Top