i’m setting up mail account xy @ chat. dyn. uucp. hu, i have logs from the server hosting its mail and web, but i do not see requests for the autoconfig file. /.well-known/autoconfig/mail/config-v1.1.xml should be looked up, right? no mention of “autoconfig”/“autodiscover”/“xml” in the DC log. you may test against this domain.
Delta Chat version
1.20.5-fat
Expected behavior
it finds the mailserver settings in the autoconfig xml.
Actual behavior
it tries out several common settings.
Steps to reproduce the problem
- enter the email address above as a new account
- enter a dummy password
- approve new account
Delta Chat requests only https:// URL, as it’s very important not to take configuration settings from untrusted sources. Your TLS certificate is self-signed, so Delta Chat does not accept it.
Get a certificate via https://letsencrypt.org/ with a https://certbot.eff.org/ or similar software.
oh, i see, i missed that.
altough it should be appear in DC logs somehow, IMO.
to the central CA providers: i dislike the idea that a 3rd paty (CA providers) can block users accessing my site by unilaterally revoking the cert it gave to me. and also, x509 implementations does not allow certs signed directly by 2 or more independent parties, so if a CA or the browser vendor decided that my cert is rotten, then i manually have to switch to a new cert issuer, rather having multiple signs on my cert among which at least 1 has to be valid.
self-signed certs may be regarded as TOFU security model, just like Autocrypt is. why approving Autocrypt’s TOFU model, but not TLS’s self-signed certs?
(altough my site is not self-signed, but signed by my own root CA which nobody recognizes 
)
anyways, thanks the hint that EFF also provides free certs! (cancel, it’s LE under the hood)
is it planned to support getting imap/smtp configs from SRV DNS records, BTW?
I opened “Advanced settings” and clicked “Show log” at the bottom of it after failed configuration, there are messages “Requesting URL …” followed by “Can’t read URL … (unable to get local issuer certificate)”.
to the central CA providers: i dislike the idea that a 3rd paty (CA providers) can block users accessing my site by unilaterally revoking the cert it gave to me.
Only if certificate revocation is checked via OCSP. As far as I know only browsers do it. Delta Chat doesn’t, so your email server certificates can’t be revoked this way. OCSP has other privacy issues too, you have to contact central server to check for certificate revocations, certainly not private and only works when you have a connection to the global Internet, while DC works as long as you have connection to the email server even if you move it into the LAN disconnected from the rest of the internet.
I am not sure, but I think it’s called cross-signing and OpenSSL supports it.
Because in this case every use is the first use, we are configuring a new account. And if attacker sets wrong SMTP and IMAP hosts in your client, e.g. their own proxy, then your client will be MITMed permanently, even when you move to another more secure LAN or VPN.
Nobody is working on it now, but if it is supported then SRV records should only be used with DNSSEC for the same reason: add support for RFC 6186 for server autoconfiguration · Issue #1508 · deltachat/deltachat-core-rust · GitHub
We can also use them without checking if they are the subdomain of the address.
zerossl.com
nice. it seems LE is strangely the only free CA. this does not improve my confidency in TLS PKI 
it’s not only OCSP i’m afraid, CA providers publish CRL as well which UAs usually respect, and there are blacklisted certs distributed by OS vendor. i dont know how DC’s TLS implementation handles/ignores CRLs or blacklisted certs exactly but once i set up https://autoconfig.<domain>, it must conform all TLS clients: DC, Thunderbird, and browsers too, since I can not distinguish clients before TLS handshake. (well, one can employ more https configs but at most 2: one for autoconfig.<domain>/mail/… and one for <domain>/.well-known/… – but this is a hack even at my standards 
) . Cross-signed certs may help – thanks for the hint.
TOFU
i’m a bit disagree: it is not neccessarily always first use - say you setup a@domain, then b@domain later on, then c@domain… in this case <domain>'s cert (or the issuer’s cert) might be remembered. if this theoretical TLS-TOFU model would work on the OS level, then it’d be more protective (ie. you visit a website earlier on this domain). indeed, it’s less useful if each particular app does it on its own, rather than managing user-approved cert issuers system-wide.
on the other hand, i agree that compromised TLS-TOFU impacts more seriously than Autocrypt-TOFU.
config by DNS-SRV
good to see that there was an initiative for it. i agree that an extra “is-subdomain?” check would be overrestrictive.
sorry for the many off-topics, i’m happy to get involved in DC.