[Gpg4win-users-en] key 0xEC70B1B8 trustable ? Self-signed SSL cert in DANE dnssec ?
Bry8 Star
bry8star at yahoo.com
Thu Nov 21 11:26:05 CET 2013
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Bernhard,
THANKS.
your email was also gpg signed :)
pls if you kindly also see few info i posted below, in between
yours, if you have time/chance, thanks in advance.
Received from Bernhard Reiter, on 2013-11-20 3:15 AM:
> Hi Bry8,
>
> On Saturday 16 November 2013 at 17:09:35, Bry8 Star wrote:
>> Is the gpg4win pkg signing key 0xEC70B1B8 trust-able ?
>
> yes (up to a certain point, which is normal for all certificates).
>
> At Intevation about 10 people have access to the certificate
> and its length is 1024D. So it is _not_ a high security certificate,
> but was considered sufficient to secure contents integrity three years ago.
>
>> What is the full fingerprint ?
>
> pub 1024D/EC70B1B8 2010-03-19 Intevation File Distribution Key
> <distribution-key at intevation.de>
> Primary key fingerprint: 61AC 3F5E E4BE 593C 13D6 8B1E 7CBD 620B EC70 B1B8
>
>> Why it's full key is not shown over a HTTPS secured webpage ?
>
> It is at https://ssl.intevation.de/Intevation-Distribution-Key.asc
> We should link this from http://gpg4win.org/package-integrity.html
> good point.
>
>> Why WK (Werner Koch) has not signed it ?
>
> Werner does not sign many certificates anymore.
> Also I think we have never asked him. :)
>
>> How a regular FIRST time gpg4win users suppose to trust binary
>> packages ?
>
> The executable is signed by
> ID: 0x00CFA0EC
> S/N: 112117F638BDC993B761C6073D63C2F86EC4
> Issuer: /CN=GlobalSign CodeSigning CA - G2/O=GlobalSign nv-sa/C=BE
> Subject: /CN=Intevation GmbH/O=Intevation
> GmbH/L=Osnabrueck/ST=Niedersachsen/C=DE/EMail=codesigning at intevation.de
> validity: 2013-06-20 14:48:08 through 2016-09-10 09:27:26
> key type: 2048 bit RSA
> key usage: digitalSignature
> ext key usage: codeSigning (suggested)
> policies: 1.3.6.1.4.1.4146.1.50:N:
> fingerprint: 15:94:27:DA:C1:6E:68:A4:DD:47:EF:04:D2:17:C5:56:00:CF:A0:EC
>
> GobalSign's root certificate is in the Microsoft Certificate "Program",
> so if you trust your operating system's standard root certificates
> you could trust this check as well.
>
> To us this is the way most users would expect this to happen,
> integrity get's checked by their operating system.
> The other methods are additional ways.
>
>
>> Why are you not signing your website's DNS with DNSSEC ? (or Why are
>> you not placing your site's DNSSEC code in ISC DLV (free) site ? )
>>
>> Why are you not declaring your own website's own SSL cert's hash in
>> the TLSA/DANE dns record ?
>
> Right now we are not serving gpg4win.org via https, this is because we did not
> buy a full https certificate for it. As you know, each full domain name needs
> a paid for ssl certificate (about 400 Euro /2 years) and this needs to be
> configured. Partly this is about the effort, partly we are sceptics of the
> PKI systems with the common set of browser root certificates. They are way to
> expensive and not many checks done, so why pay them even that little?
>
first pls pardon me, as i will be repeating many known things, just
trying to transfer/suggest basic ideas or alternatives toward
mailing-list, may be useful at different areas:
(and sorry, some are too detail & some are less)
(and also sorry for posting long email, but should be helpful for
other cases)
here, "you" = gpg4win.org group, AND, any other domain-name/zone
owner person or group or project.
DANE+DNSSEC DNS now allow any domain-name's/zone's owner
him-self/her-self/them-self, to become their own root cert CA
(Certificate Authority), for free.
pls consider : to create one (or two) free openssl (or similar)
based self-signed end-entity/domain-issued/server SSL / TLS
certificate for your own domain-name/zone: gpg4win.org or
www.gpg4win.org . (or obtain free SSL cert from www.CAcert.org) .
then add that free SSL cert in your own web-server software Apache
(debian) for port 443 traffic . then either calculate full hex code
or calculate sha-256 based hash hex code, of that SSL cert, either
by using tools which are now included with the ISC BIND package, or
use simple shell command [reference SSL-DER-2-TLSA-Hash] on the
SSL's public .pem/.crt file, to get full hex code . declare/share
SSL cert's FULL (or hash) hex code via your DNS server's zone file,
by using such dns records:
_443._tcp.www.gpg4win.org. 360 IN TLSA 3 0 0 C_A_D_www-gpg4win-crt
if you created ssl cert for www.gpg4win.org.
_443._tcp.gpg4win.org. 360 IN TLSA 3 0 0 C_A_D_gpg4win-crt
if you created ssl cert for gpg4win.org.
(others will/may recommended using partial hash hex in TLSA, not me
. full TLSA clearly defines+declares+shares with visitors, what
exactly need to be trusted, without any confusion . those who want
to save few bytes even in an ever increasing high bandwidth internet
era, let them use hash hex in TLSA, but they shouldn't . security is
not about what is enough or based on an assumption, and its not
about waiting for finding PUBLIC weakness in that "enough", like
md5, sha1, etc which no one should use anymore, using FULL hex code
of full (very strong) SSL/TLS cert is very & more important . a
non-security related product/service seller/author/developer may use
hash hex in TLSA , seems ok . but an entity who wants to enhance
security, have no reason to use hash hex in TLSA . SSL cert (in
web-server) is for SECURING the CONNECTION when delivering webpages
and important text info, codes, small images, etc over HTTPS
encrypted, (and if privacy requires, then large files should be
pre-encrypted (GPG, AES, etc) at server-side before delivering to
user side), and then large files must be delivered over HTTP (or P2P
or FTP etc) non-encrypted connection, and end-user or end-client
MUST need to verify received file's integrity using the GPG
signature codes/files obtained over HTTPS encrypted connection ...
in that way servers will not be overloaded, more bytes/bandwidth
will remain for better purpose . SSL cert defined in LSA/DANE
(almost) eliminates the chance if suddenly someone
attacking/hijacking/spoofing/faking a website/webservice . full TLSA
also helps users/visitors who use different types of connection
methods like, various type of vpn, proxy, etc to enhance security
further . full key enhances "Privacy" rights . so pls do not
support/encourage such which can/will be used for violating Privacy
rights).
if you are using only one server/end-entity SSL cert for all
services, then:
TLSA 3 0 0 is used when full hex of full SSL cert is declared in dns.
TLSA 3 0 1 is used when SHA-256 hash hex of full SSL cert is declared.
but i think better is to create your own ROOT CERT, and declare that
root cert (trust-anchor/TA) via using the TLSA 2 0 0 in DNS, and
then also declare other SSL certs which are under your own/that root
cert, via using TLSA 1 0 0 or TLSA 3 0 0 based dns records . create
separate SSL cert (under your own/that root/TA cert) for www, mail,
ftp, gpg/keyserver, etc services/servers.
;a sample (not tested) zone file [begin] :
gpg4win.org. 3600 IN SOA s1.gpg4win.org. hostmaster.gpg4win.org.
2013112010 18000 3600 864000 3600
; zone signing software will create below 2 lines:
;gpg4win.org. 3000 IN DNSKEY 256 3 8 HEX_CODE_KEY
;gpg4win.org. 3000 IN DNSKEY 257 3 8 HEX_CODE_KEY
gpg4win.org. 3000 IN NS s1.gpg4win.org.
gpg4win.org. 3000 IN NS s2.gpg4win.org.
gpg4win.org. 300 IN A IP.ADRS_S-1_IPv4
gpg4win.org. 300 IN A IP.ADRS_S-2_IPv4
; IP-address of "s" will be "round-robin" based:
s.gpg4win.org. 300 IN A IP.ADRS_S-1_IPv4
s.gpg4win.org. 300 IN A IP.ADRS_S-2_IPv4
mail.gpg4win.org. 300 IN A IP.ADRS_S-1_IPv4
mail.gpg4win.org. 300 IN A IP.ADRS_S-2_IPv4
keys.gpg4win.org. 300 IN A IP.ADRS_S-1_IPv4
keys.gpg4win.org. 300 IN A IP.ADRS_S-2_IPv4
s1.gpg4win.org. 900 IN A IP.ADRS_S-1_IPv4
s2.gpg4win.org. 900 IN A IP.ADRS_S-2_IPv4
; CNAME
www.gpg4win.org. 300 IN CNAME s.gpg4win.org.
_http._tcp.gpg4win.org. 300 IN SRV 0 0 80 www.gpg4win.org.
_https._tcp.gpg4win.org. 300 IN SRV 0 0 443 www.gpg4win.org.
_http._tcp.www.gpg4win.org. 300 IN SRV 0 0 80 www.gpg4win.org.
_https._tcp.www.gpg4win.org. 300 IN SRV 0 0 443 www.gpg4win.org.
; email system:
gpg4win.org. 300 IN MX 10 mail.gpg4win.org.
gpg4win.org. 1800 IN MX 20 s1.gpg4win.org.
gpg4win.org. 1800 IN MX 20 s2.gpg4win.org.
; load balancing:
_smtp._tcp.gpg4win.org. 300 IN SRV 10 0 25 mail.gpg4win.org.
_smtp._tcp.mail.gpg4win.org. 300 IN SRV 10 0 25 mail.gpg4win.org.
_smtp._tcp.mail.gpg4win.org. 1800 IN SRV 20 0 25 s1.gpg4win.org.
_smtp._tcp.mail.gpg4win.org. 1800 IN SRV 30 0 25 s2.gpg4win.org.
_submission._tcp.gpg4win.org. 300 IN SRV 10 0 587 mail.gpg4win.org.
_submission._tcp.mail.gpg4win.org. 1800 IN SRV 10 0 587
mail.gpg4win.org.
_submission._tcp.mail.gpg4win.org. 1800 IN SRV 20 0 587 s1.gpg4win.org.
_submission._tcp.mail.gpg4win.org. 1800 IN SRV 30 0 587 s2.gpg4win.org.
_imaps._tcp.gpg4win.org. 300 IN SRV 0 0 993 mail.gpg4win.org.
_imaps._tcp.mail.gpg4win.org. 300 IN SRV 0 0 993 mail.gpg4win.org.
_imaps._tcp.mail.gpg4win.org. 900 IN SRV 1 0 993 s1.gpg4win.org.
_imaps._tcp.mail.gpg4win.org. 900 IN SRV 2 0 993 s2.gpg4win.org.
; DANE/TLSA:
_443._tcp.gpg4win.org. 360 IN TLSA 1 0 0 C_A_D_gpg4win-crt
_443._tcp.gpg4win.org. 360 IN TLSA 2 0 0 C_A_D_root-crt
_443._tcp.www.gpg4win.org. 360 IN TLSA 1 0 0 C_A_D_www-gpg4win-crt
_443._tcp.www.gpg4win.org. 360 IN TLSA 2 0 0 C_A_D_root-crt
; Combining/reducing TLSA total bytes, using CNAME & common cert:
; _port._proto.zone. [TTL] IN TLSA u s m C_A_D
_60._tcp.mail.gpg4win.org. 360 IN TLSA 1 0 0 C_A_D_mail-gpg4win-crt
_60._tcp.mail.gpg4win.org. 360 IN TLSA 2 0 0 C_A_D_root-crt
_25._tcp.mail.gpg4win.org. 360 IN CNAME _60._tcp.mail.gpg4win.org.
_25._tcp.s1.gpg4win.org. 360 IN CNAME _60._tcp.mail.gpg4win.org.
_25._tcp.s2.gpg4win.org. 360 IN CNAME _60._tcp.mail.gpg4win.org.
_587._tcp.mail.gpg4win.org. 360 IN CNAME _60._tcp.mail.gpg4win.org.
_587._tcp.s1.gpg4win.org. 360 IN CNAME _60._tcp.mail.gpg4win.org.
_587._tcp.s2.gpg4win.org. 360 IN CNAME _60._tcp.mail.gpg4win.org.
_993._tcp.mail.gpg4win.org. 360 IN CNAME _60._tcp.mail.gpg4win.org.
_993._tcp.s1.gpg4win.org. 360 IN CNAME _60._tcp.mail.gpg4win.org.
_993._tcp.s2.gpg4win.org. 360 IN CNAME _60._tcp.mail.gpg4win.org.
_443._tcp.keys.gpg4win.org. 360 IN TLSA 1 0 0 C_A_D_keys-gpg4win-crt
_443._tcp.keys.gpg4win.org. 360 IN TLSA 2 0 0 C_A_D_root-crt
_443._tcp.s1.gpg4win.org. 360 IN CNAME _443._tcp.keys.gpg4win.org.
_443._tcp.s2.gpg4win.org. 360 IN CNAME _443._tcp.keys.gpg4win.org.
; sample zone file [end].
so your SSL/X.509 PKIX structure for your domain/zone will be:
1. - Gpg4win root/TA/CA cert
2. - - Service certs (www, mail, keys)
so each service will have at-least two TLSA , for better checking .
(and pls see CNAME based reduced TLSA usage and redirection).
another alternative than above zone-file, is to use a
standalone/end-entity SSL cert for HTTPS webpages, and keep other
services, like email, keyserver, ssh, etc under your own Root/TA/CA
cert . then users can quickly verify if initial HTTPS connection is
DANE/TLSA secured or not (without loading the root cert) . then show
info/instruction on homepage for users, to load your(gpg4win)
root/ta/ca cert int heir web-browser, email-client for other
services like: email, keyserver, ssh, etc.
last ISC BIND/named DNS-Server now have protection against all
latest DNS attacks . enable built-in RRL (and other adaptive
rate-limiting features) in named/BIND.
then DNSSEC-sign your domain-name "gpg4win.org" zone file, by using
free tools included with BIND.
if your domain-name's seller company, DOMAIN REGISTRAR, do not yet
support DNSSEC, then configure zone file for DLV usage and submit
your DNSSEC DLV code for free into ISC DLV DNS service.
if your DOMAIN REGISTRAR do support DNSSEC, or to figure it out, and
to read few more articles on DNSSEC.
contact your domain registrar for initial support related question,
after checking below webpage.
How to secure & sign domain-name with DNSSEC:
https://www.internetsociety.org/deploy360/resources/dnssec-registrars/
then get a note-paper, for key management related note, for your
domain-name : dnssec uses 2 types of keys : KSK, ZSK . ZSK's public
portion is for your own zone . KSK's public portion is for your
Domain Registrar . then configure zone file to use DNSKEY based on
(two) ZSK(s) initially, (and create KSK's public portion's (DS)
hash), and then send your KSK's public portion to your domain
registrar, along with your NS records info, or connect very securely
with your domain-name's domain-registrar's DNSSEC related
configuration webpage, and update/submit key there, domain-registrar
will auto-process it and send to (and link with) parent registrar.
Initially start with two ZSKs : zsk1, zsk2 for your zone, so you can
change dns records anytime during initial dnssec based zone
configurations . basically one zsk will have to verify older dns
records, and another zsk will have to verify your newly added dns
record or when you changed any existing dns record slightly, and you
will have to add a new zsk everytime after a change, for future use
. and delete older zsk when longest TTL time used in your zone has
passed . see the dnssec key management & key rollover article/rfc
for details, and choose one of the key rollover model that best
suits for your ability & need, and write that down on that initial
note-paper.
https://tools.ietf.org/html/rfc6781
then pls instruct your users/visitors, to use firefox or icecat or
iceweasel etc, and load "Extended DNSSEC Validator" & "DNSSEC
Validator" free addon/extension . pls tell users/visitors, for
better security to load their own FULL dnssec supported free 3rd
party dns server or dns resolver software, like : BIND from ISC.org,
Unbound from NLnetLabs.nl, DNSSEC-Trigger from NLnetLabs.nl, etc,
and run any one of them on 127.0.0.1:53 (ipAddress:port) as a local
DNS-Server / DNS-Resolver, and then specify that dns-server's
ip-address inside those two addon/extension's settings, and then
also specify inside the (Windows) Local Area Network Adpater's
(wired & wireless) DNS-Server's primary DNS-Server settings, just
use 1 dns server 127.0.0.1 (or, if you have any/another 2nd
dns-server, on your own local LAN or local VM, such dns-server must
to have full dnssec supported DNS-Server . most general routers are
not full dnssec supported dns server) . If using ISC DLV, instruct
users/visitors to enable ISC DLV checking feature in their DNSSEC
DNS-Server . pls tell/instruct users/visitors to load your (gpg4win
site's own) ROOT cert in visitor's web-browser . And then pls tell
users to get your package signing gpg key's full key and keyid over
an encrypted HTTPS and DANE/TLSA verified webpage & dnssec secured
connection.
when above conditions are true, then, users/visitors can goto
HTTPS://gpg4win.org or HTTPS://www.gpg4win.org site, from their own
web-browser (firefox, icecat, etc) and can see visible DNSSEC+DANE
related ICON & information, if a webpage/website (gpg4win.org) is
really using the SSL certificate defined in the TLSA/DANE DNS record
or not, or using a fake/forged SSL cert . and then users/visitors
can obtain authentic keyid or full gpg pub key (GnuPG package
signing related) from your HTTPS secured & encrypted webpage, with
higher confidence level.
so, first, pkg signing FULL pub GPG/PGP key, must be obtained over
SSL/HTTPS secured connection, then other stuff can be done over HTTP
non-encryptedly. If pkg signing pub key were to include "signature"
code, of some very trustworthy person, or trusted-group, and IF
user/visitor also have that "trustworthy" key in their GPG/PGP
keyring, and if users/visitors know how to check it, then such pkg
signing key, could have been trusted (after observing correct
"signature" codes), even when obtained over a HTTP non-encrypted
connection . obviously it is not possible : that all humans from all
location of earth or outside are trying to meet with one
entity/person physically face-to-face, to create a trustworthiness
of/for a specific public key.
DNSSEC's DANE feature has enabled domain-name owners to use their
own free SSL cert, for free, for creating secured connections and to
share data with users without eavesdroppers and without any
modification in the middle of the way . those web-browser
addons/extensions can also show further info such as these : if the
IP-address used by the web-browser is defined in DNSSEC DNS, and has
matched, or spoofed/wrong ip-address is used . if dnssec
authentication codes of a DNSSEC-signed domain-name are working
properly or not , SSL/TLS cert is under a CA or root cert or none,
if under a CA or root cert then has it passed PKIX auth or not, if
encrypted connection using correct SSL cert or forged cert, etc .
also see DNSSEC NSEC3 related info.
For general users, if they can see such an ICON/feature in
Firefox/IceCat which can show such info : "Domain-name "gpg4win.org"
is secured by DNSSEC, and the certificate is not validated by CA,
and the certificate is DANE verified. Your connection to
"gpg4win.org" website is encrypted to prevent eavesdropping" ...
then such is fairly enough/suffice "security".
"validated by CA", will be shown for such SSL certificates when
domain-name's owner has bought/purchased SSL cert, or when owner has
obtained free SSL cert from such as : CAcert.org, etc or when
user/visitor have loaded your/Gpp4Win group's Root/TA cert in their
web-browser ... Basically any SSL cert which is under a Root Cert or
Intermediate Cert, and if such Root or Intermediate Cert already
pre-existed/pre-included inside firefox/icecat web-browser, then
addon will show: Validated by CA.
But anyway, that "Validated by CA" is not a MUST required for a
"secured" connection . To use a secured connection, a SSL cert only
need to be DANE (or TLSA) verified and/or DANE/TLSA Validated,
means, a SSL cert MUST need to be verified against the TLSA DNS
record, what that domain-name's/zone's actual owner wanted
user/visitor to use, and its all for FREE . only someone will have
to spend spare/extra/free time to complete it . if you create a very
strong SSL certificate which is valid for 2 years, then after doing
once, next time you will do these after 2 years . but obviously for
more security, it is better to change/update dnssec related signing
codes, changing ZSK, after each 6 month or 1 yr or upto you, or when
any upper zone/domain level's key rollover event happens (which is
very rare).
Windows users can export visited website's SSL cert's pem code into
a file, from their web-browser, and can calculate hash hex or full
hex, using tools set from CYGWIN package, and cygwin's or ISC-BIND's
"dig" command can show, what is actually declared by you, for
securing the gpg4win.org, in TLSA DNS record:
dig @127.0.0.1 -c in -t TLSA _443._tcp.www.gpg4win.org. +dnssec
or
dig @127.0.0.1 -c in -t TLSA _443._tcp.gpg4win.org. +dnssec
if dig result have "AD" flag and NOERROR status, (from a full dnssec
supported LOCAL dns-resolver or dns-server), then that is very
strong check and very accurate way to obtain authentic TLSA code for
a site/domain-name.
it is also possible to DECLARE your binary/source's GPG-signing
key's key-id, fingerprint, (associated email address) and full
public gpg key, etc in DNS record like, "CERT PGP" . then users can
obtain authentic fingerprint and/or authentic full gpg pub key,
using simple "dig" command, or commands included in GnuPG software
tool, directly from DNSSEC BASED DNS, and then they can also verify
if received files are authentic or not.
in my understanding , dnssec do not reduce need for GPG/PGP .
GPG/PGP is a human/end-entity centric personal direct user-to-user /
human-to-human / ee-2-ee encryption security system for
messaging/communicating . and dnssec is also a partial form of like
GPG/PGP/OpenPGP, where your dnssec KSK key & name-servers are
vouched by your upper layer, and you are vouching your lower layer's
KSK key and their name-servers . like gpg public key, a "signature"
code from another user in a public key tells others who has
trusted+verified identity of a public key & associated name &
associated email address . in this way based on WoT, a user can
create "chain-of-trust" for a collection of public-keys . dnssec is
not a complete single-server based centralized data sharing security
system , as any zone/domain owner can directly request/instruct all
public users to add their(zone owner's) DLV/DS etc key directly into
their dns-server, to create another form of "chain-of-trust" .
if situation demands or necessary, dns-server software can be
modified & configured to use other DLV DNS-Servers and/or other
dnssec based alternative Root Servers, (if "trust" in ICANN's
root.key, is compromised even for once, by the way which never
happened so far), and then, even a voting mechanism based DNSSEC-DNS
system can be used from different geo/political/demographic
location's DNS-Servers . So DNSSEC based DNS
solutions/implementations will not go away.
dnssec creating connection's security for new+unknown
global/wider/community level . gpg/pgp creating known end-to-end
(e2e) security . together , they are even better .
>
> Securing DNS better is an idea, we will think about.
> (It competes with a lot of other ideas how to improve the Gpg4win security
> and user experience. And we are in search of funding.)
>
> Thanks for your suggestions!
> Bernhard
>
mentioned are all free solutions . and gpg4win definitely needs more
funding . then pls enable in future : HKPS feature in gpg4win , a
way/option to disable gpg-agent (if not needed for a particular
implementation) , enable dane/TLSA checking during HKPS connection
(and adding some indicative meta-tag, by the way, GnuTLS already
supports DANE+DNSSEC) , portable gpg4win (as GPG related email is
accessed more from multiple location from USB portable drive,
current gpg4win seems to be fixed with fix location, when in
portable mode, it need stay within owner's usb drive), etc.
REFRENCES & END:
SSL-DER-2-TLSA-Hash : a bash shell command:
{ openssl x509 -in SSL-cert-file.pub.crt \
-outform DER | \
hexdump -v -e '"" 1/1 "%02X" ""' \
;echo; } > SSL-cert-file.full-cad.tlsa
Use above as one line command, after removing the backslash ("\")
symbols, and join all 4 lines.
Code shown on screen and saved in SSL-cert-file.full-cad.tlsa file,
is the FULL TLSA C_A_D code of FULL SSL cert, and this code is what
you will have to use to replace below C_A_D words shown in below
TLSA DNS record:
C_A_D_www-gpg4win-crt
C_A_D_gpg4win-crt
_443._tcp.www.gpg4win.org. 360 IN TLSA 3 0 0 C_A_D_www-gpg4win-crt
_443._tcp.gpg4win.org. 360 IN TLSA 3 0 0 C_A_D_gpg4win-crt
During test/initial phase use (shorter) TTL 360, but after setup
completes, use slightly longer TTL.
DANE/TLSA:
(TLSA : DNS-Based Authentication of Named Entities TLS)
https://tools.ietf.org/html/rfc6698
DNSSEC : (Domain Name System Security Extensions)
https://tools.ietf.org/html/rfc4033
https://tools.ietf.org/html/rfc4034
https://tools.ietf.org/html/rfc4035
CAD/cad/C_A_D :
Certificate Association Data (used in TLSA dns rr).
PIR : The Public Interest Registry, the registry for .org, maintains
list of registrars supporting DNSSEC:
http://www.pir.org/get/registrars?order=field_dnssec_value&sort=desc
Few DANE/TLSA-signed test sites:
https://www.internetsociety.org/deploy360/resources/dane-test-sites/
TLSA tester:
https://www.had-pilot.com/dane/danelaw.html
https://check.sidnlabs.nl/dane/
TLSA perl script for SSL hash hex or full hex:
rename attached file: der2tlsa_pl into der2tlsa.pl before using.
ISC DLV:
https://dlv.isc.org/about/requirements
List of TLDs, see "DNSSEC" column:
http://en.wikipedia.org/wiki/List_of_Internet_top-level_domains
RIPE NCC, Global DNSSEC Deployment:
https://labs.ripe.net/Members/wnagele/dnssec-deployment-today
https://www.internetsociety.org/deploy360/dnssec/maps/
DNSSEC Key Rollover:
https://tools.ietf.org/html/rfc6781
There are many other small tidbits to enhance security, (for
different level of users), which i couldn't post here . by no means,
these will remain always same, new weakness exist in all
technologies, as human have curiosity and weakness automatically
shows/surfaces up, and when addressed then we will have to learn &
bypass attacks/weaknesses, and stay one extra step ahead.
(and pls pardon mistakes)
Thanks for reading/scanning,
- -- Bright Star.
-----BEGIN PGP SIGNATURE-----
iL4EAREKAGYFAlKN37tfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldDEyQjc3RjJDOTJCRjI1QzgzOEM2NEQ5Qzg4
MzZEQkEyNTc2QzEwRUMACgkQiDbboldsEOy4KQEA6kLtKFhofF+noVvWjrkIzhIX
fPwjqtos500QK+8nS/gBAJO3cY7fWq52whLFdebfl7WfFvJfN4jFINRWAnRJ9tig
=RRWH
-----END PGP SIGNATURE-----
-------------- next part --------------
#!/usr/bin/perl
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# der2tlsa.pl
# Author: Bright Star. (bry 8 st ar \@a.t\@ ya hoo d.o.t c om)
# Author: tom/tm604.
#
# SSL DER to TLSA CAD.
# Change filename from "der2tlsa_pl" into "der2tlsa.pl"
# before using.
# To create a DER SSL/TLS cert file,
# from a PEM or CRT file:
# $ openssl x509 -in SSL-cert-file.pub.pem \
# -outform DER \
# -out SSL-cert-file.pub.der
# Do not specify .crt, .pem file in commandline,
# then it will show wrong codes.
# To Convert DER content into equivalent
# TLSA Hexadecimal, and Create Hash of DER content:
use Digest::SHA qw(sha256_hex sha512_hex);
$rFN = ""; $rFN = $ARGV[0];
$m = " v1.0.201307030000. Bright Star \(bry "
."8 st ar \@a.t\@ ya hoo d.o.t c om\)\n";
die "SSL DER 2 TLSA CAD\: Specify a DER "
."based SSL filename in commandline.\n$m"
unless $rFN;
printf "SSL DER 2 TLSA CAD:\n$m\nAttempting "
."to load \"$rFN\" file...";
open my $rFH, "<", $rFN or die
" Failed To Load $rFN File For Reading: $!\n";
{ local $/; $der = <$rFH>; }
close $rFH || warn
" Failed To Close $rFN File: $!\n";
printf " loading done.\n\n";
$full_cad = $der;
$full_cad =~ s/(.)/sprintf("%02X", ord($1))/egs;
$m = "\; a DNSSEC DANE/TLSA DNS record syntax\:\n"
."\; _port._proto.[host.]domain.TLD. [TTL] IN TLSA u s m C_A_D\n\n"
."\; Replace below \"u\", based on SSL/TLS certificate\'s \"usage\"\n"
."\; field, mentioned in\:\n"
."\; https\://tools\.ietf\.org/html/rfc6698\n"
."\; Brief/Summary: \"u\" can be replaced with any one of these numbers\: 0, 1,\n"
."\; 2, 3. \"s\" can be 0 or 1, \"m\" can be 0, 1 or 2. A purchased SSL cert \(EE\)\n"
."\; from a known \(Public\) CA company which has their RootCA SSL cert already\n"
."\; pre-included in popular web-browsers, client-software, operating systems,\n"
."\; etc then declare such EE cert via \"TLSA 1 s m\" type of TLSA DNS record.\n"
."\; If domain-owner created own self-signed \(EE\) srvr SSL cert, then either\n"
."\; declare via \"TLSA 1 s m\", or, via \"TLSA 3 s m\". When \"u\" is 0, 1 or 2,\n"
."\; then DANE supported clients check Server SSL cert\'s entire \(PKIX\) chain.\n"
."\; When \"u\" is 3, then clients skip checking chain. If you want to declare\n"
."\; \(Public\) CA company\'s RootCA SSL cert, then use \"TLSA 0 s m\". To declare\n"
."\; a Root-CA SSL cert which you yourself created, or when a Root-CA SSL cert\n"
."\; is by-default not pre-included in web-browsers or client software or OS,\n"
."\; then use \"TLSA 2 s m\". When s=0 then C_A_D is based on Full SSL/TLS cert,\n"
."\; when s=1 then C_A_D is based ONLY on SPKI \(SubjectPublicKeyInfo\) portion\n"
."\; of a SSL cert. When m=0, then C_A_D has Full data of what is mentioned in\n"
."\; \"s\", when m=1 then C_A_D is based on SHA-256 hash code of \"s\", when m=2\n"
."\; then C_A_D is based on SHA-512. C_A_D = Certificate Association Data. CAD\n"
."\; = C_A_D. TTL = Time To Live, in seconds. proto=protocol. TLD = Top Level\n"
."\; Domain.\n\n"
."\; A Full C_A_D hexadecimal code of Full SSL cert\:\n\n"
."_443._tcp.www\.example\.com. 900 IN "
."TLSA u 0 0 $full_cad\n\n";
my $sha = Digest::SHA->new(256);
$sha->addfile($rFN, "b");
$sha256 = uc $sha->hexdigest;
$m .= "\; SHA-256 based C_A_D of Full SSL cert\:\n\n"
."_443._tcp.www\.example\.com. 900 IN "
."TLSA u 0 1 $sha256\n\n";
$sha = Digest::SHA->reset(512);
$sha->addfile($rFN, "b");
$sha512 = uc $sha->hexdigest;
$m .= "\; SHA-512 based C_A_D of Full SSL cert\:\n\n"
."_443._tcp.www\.example\.com. 900 IN "
."TLSA u 0 2 $sha512\n\n";
printf "$m";
$wFN = $rFN . ".cad.tlsa";
printf "Attempting to create \(or over-write\) "
."\"$wFN\"...";
open my $wFH, ">", $wFN or die
" Could Not Create \(or OverWrite\) $wFN File "
."For Writing: $!\n";
{ print $wFH "$m"; }
close($wFH) || warn
" Failed To Close $wFN File: $!\n";
printf " file created, info saved.\n";
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x576C10EC.asc
Type: application/pgp-keys
Size: 5357 bytes
Desc: not available
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-users-en/attachments/20131121/c0883410/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: der2tlsa_pl.sig
Type: application/octet-stream
Size: 192 bytes
Desc: not available
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-users-en/attachments/20131121/c0883410/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x576C10EC.asc.sig
Type: application/octet-stream
Size: 192 bytes
Desc: not available
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-users-en/attachments/20131121/c0883410/attachment-0001.obj>
More information about the Gpg4win-users-en
mailing list