61–70 of 250 posts
The majority of CloudFlare's IP addresses are blocked by China's great firewall, which means CloudFlare is out of the question if you expect that your website will be visited by Chinese users.
I hope in the (near) future, they'll enforce not using unsafe NIST curves for that, too. I don't think Internet Explorer supports Curve25519 or other safer curves right now, but it might in the future, and I hope they will make their move then.
Also, I hope Cloudflare has tripled its security team along with this, because they're going to be #1 on NSA's "to-break" list now.
EDIT: Won't work: You need to verify that you own the domain by pointing your NS records to cloudflares nameservers. What prevents me from doing this MITM attack in (for example) a public wifi: I add a domain I don't own (example.com) to my cloudflare account. Then I point a hostname (www.example.com) to an IP address I own (1.2.3.4). From what I understand, cloudflare now serves HTTPS for this domain through their p…
That wouldn't work. CloudFlare isn't acting as the RA (the person verifying you own example.com). They serve a verification file at example.com, but the bot cannot see this file as example.com isn't pointing to CloudFlare.
Earlier quoted context omitted.
> this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting It does nothing of the kind, it has always been the case that seeing the SSL padlock only informed you that the connection to whichever server you are communicating with is encrypted and nothing more. Do you not recall the age of customer feedback pages hosted behind SSL that actually just sent plain…
The centralization argument still has merit. If this catches on big time, there's only one company to coerce/compromise, to backdoor a bunch of services at once. Arguably the CA/ISP structure is like this already, but this may be worse.
Earlier quoted context omitted.
That wouldn't work. CloudFlare isn't acting as the RA (the person verifying you own example.com). They serve a verification file at example.com, but the bot cannot see this file as example.com isn't pointing to CloudFlare.
Not sure I'm following you. Probably because I didn't use SSL on cloudflare before, so I don't know about any verification file. How does that work? I guess before serving SSL traffic for a domain they verify both that the nameserver for a domain is actually one of cloudflares nameservers AND they test for the presence of some kind of signed file that has to be reachable on the domain you added?
The majority of CloudFlare's IP addresses are blocked by China's great firewall, which means CloudFlare is out of the question if you expect that your website will be visited by Chinese users.
1) That's not actually accurate; and 2) Just wait for the next trick we have up our sleeve ( https://blog.cloudflare.com/one-more-thing-keyless-ssl-and-c... )
I see you have big plans for China :) Looking forward to seeing your new data centers coming online. How do you plan to solve the mandatory ICP Registration problem for your customers?
Earlier quoted context omitted.
Isn't provisioning certs without at least a simple human interaction from the domain holder against CA rules?
No, I don't think that exists at least in the CA/B Baseline. You have to have consent, obviously, but that's obtained when you sign up for CloudFlare.
https://cabforum.org/wp-content/uploads/Baseline_Requirement...
"The CA MUST ensure that the certificate is issued with the consent of, and according to procedures established by, the owner of each Domain Name"
EDIT: Here are the established authorization procedures:
"11.1.1 Authorization by Domain Name Registrant
For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant’s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as “Applicant” for the purposes of this section) either is the Domain Name Registrant or hascontrol over the FQDN by:
1. Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar;
2. Communicating directly with the Domain Name Registrant using an address, email, or telephone number provided by the Domain Name Registrar;
3. Communicating directly with the Domain Name Registrant using the contact information listed in the WHOIS record’s “registrant”, “technical”, or “administrative” field;
4. Communicating with the Domain’s administrator using an email address created by pre-pending ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ inthe local part, followed by the at-sign (“@”), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN;
5. Relying upon a Domain Authorization Document;
6. Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN; or 7. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described. "
IANAL and I'm sure that CF has had this double checked, but I still think it's a bold move to issue certs on their own account.
Earlier quoted context omitted.
If Windows XP and Internet Explorer then they'll get a SSL error if visiting via HTTPS. Won't have a problem over HTTP.
Just a normal SSL error, or would they be able to see another site? I had an issue like this with SNI where a client reported being able to see another site that was on the same IP. The issue was that she was using IE on Windows XP, and SNI didn't work.
The following two https sites exist on the same IP:
grepular.com emailprivacytester.com
If your browser doesn't support SNI, then the cert for "grepular.com" will be returned by default. So browsers which don't support SNI will not notice anything unusual when visiting https://grepular.com/, but will get the cert for grepular.com instead of emailprivacytester.com when visiting https://emailprivacytester.com/
Unless you have IPv6 support, in which case the sites have different IPs so SNI isn't required (exactly like cloudflare have just done)
EDIT: Won't work: You need to verify that you own the domain by pointing your NS records to cloudflares nameservers. What prevents me from doing this MITM attack in (for example) a public wifi: I add a domain I don't own (example.com) to my cloudflare account. Then I point a hostname (www.example.com) to an IP address I own (1.2.3.4). From what I understand, cloudflare now serves HTTPS for this domain through their p…
Earlier quoted context omitted.
Not sure I'm following you. Probably because I didn't use SSL on cloudflare before, so I don't know about any verification file. How does that work? I guess before serving SSL traffic for a domain they verify both that the nameserver for a domain is actually one of cloudflares nameservers AND they test for the presence of some kind of signed file that has to be reachable on the domain you added?
[deleted]