Re: [tor-talk] HSTS forbids "Add an exception" (also, does request URI leak?)
You may be interested in our paper "HSTS Supports Targeted Surveillance" that we will present at FOCI next week https://www.usenix.org/conference/foci18/presentation/syverson Amongst other things, it discusses some of the issues raised in this thread. They will post the paper on Tuesday, but if someone wants a copy now, let me know. aloha, Paul On Wed, Aug 08, 2018 at 02:32:10PM -0400, Kevin Flowers wrote: > Have you thought about running your own email server. > > -Original Message- > From: tor-talk [mailto:tor-talk-boun...@lists.torproject.org] On Behalf Of > Need Secure Mail > Sent: Wednesday, August 8, 2018 12:28 PM > To: tor-talk@lists.torproject.org > Subject: Re: [tor-talk] HSTS forbids "Add an exception" (also, does request > URI leak?) > > On August 8, 2018 1:57 PM, Matthew Finkel wrote: > > > Right. This is the recommendation in the RFC [0]. It would be > > counter-productive if the webserver informed the browser that the > > website should only be loaded over a secure connection, and then the > > user was given the option of ignore that. That would completely defeat > > the purpose of HSTS. > > > > [0] https://tools.ietf.org/html/rfc6797#page-30 > > Section 12.1 > > Thanks, I was already quite familiar with the RFC. I know its rationale. > > But it is an absolute rule that *I* get the final word on what my machine > does. That is why I run open-source software, after all. I understand that > most users essentially must be protected from their own bad decisions when > faced with clickthrough warnings. I have read the pertinent research. It's > fine that the easy-clickthrough GUI button is removed by HSTS. However, if > *I* desire to "completely defeat the purpose of HSTS", then I shall do so, > and my user-agent shall obey me. I understand exactly how HSTS works, and I > know the implications of overriding it. > > >> This error made me realize that Tor Browser/Firefox must load at > >> least the response HTTP headers before displaying the certificate > >> error message. I did not realize this! I reasonably assumed that it > >> had simply refused to complete the TLS handshake. No TLS connection, no > >> way to know about HSTS. > > > > Why? There are three(?) options here: > > > > 1) The domain is preloaded in the browser's STS list, so it knows > > ahead of time if that site should only use TLS or not. > > Although I did not check the browser's preload list, I have observed this on > a relatively obscure domain very unlikely to be on it... > > > 2) The domain is not in the preloaded list, so the browser learns > > about the website setting HSTS on its first successful TLS connection > > and HTTP request. > > ...as to which I had never yet successfully made a TLS connection in that > temporary VM, with a fresh Tor Browser instance which had never before > visited *any* sites... > > > 3) The user previously loaded the site and the browser cached a STS > > value for that domain. > > ...and thus of course, could not save anything from previous loads of the > site. My whole browsing setup is amnesiac. I literally use a new VM with > "new" Tor Browser installation for each and every browsing session. No cached > STS value! > > >> Scary. How much does Tor Browser actually load over an > >> *unauthenticated* connection? Most importantly, I am curious, does it > >> leak the request URI path (including query string parameters) this > >> way? Or does it do something like a `HEAD /` to specifically check > >> for HSTS? No request headers, no response headers, no way to know > >> about HSTS. Spies running sslstrip may be interested in that. > > > > No? This was one of the main goals of HSTS. It should prevent SSL > > stripping (for some definitions of prevent). > > Key phrase: "for some definitions of prevent". > > Inductive reasoning: For a site not in the STS preload list and never before > visited, the only means for the user-agent to know about STS is to receive an > HTTP response header. The only means to receive an HTTP response header, is > to send HTTP request headers. Assume that the browser does not make an HTTP > request. How does it know that the site uses STS? > > The HTTP request headers themselves may be useful to spies. Without the > request headers, a network evesdropper only knows the hostname of the request > (via SNI, RFC 6066). With the request headers: > > 0. The request path informs the evesdropper about which news articles I am > reading on www.newspaper.dom, which people I communicate with on > www.socialmedia.dom, etc. > > 1. Query string parameters, if any, are exposed. On many sites, this can be a > severe privacy problem. On some (badly-designed) sites, it can also be a > security issue. > > 2. Some browser fingerprint information is exposed. This is a lesser issue > with Tor Browser requests from a Tor exit; any tcp/443 traffic from a Tor > exit can be presumed Tor Browser unless demonstrated otherwise.
Re: [tor-talk] [tor-relays] freehaven question.
> The project called Free Haven never got finished, because of the hard > research questions described on the front page: > https://www.freehaven.net/ Where does (or should) the line or guidepath go on such projects in the space between say bulletproof (for all, most, or some use cases), and good enough for same? When does (or should) movement occur from one reasonably well explored technology path, onto another exploration path combining newer research / architecture / tech even if wholesale, when the former is thought may no longer meet current / evolving threats for all, most, or some use cases, as may have been rightly thought for the former at its formative time in the past? Feel free to quote and rethread with a better subject as this one is probably not a good fit. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] HSTS forbids "Add an exception" (also, does request URI leak?)
Have you thought about running your own email server. -Original Message- From: tor-talk [mailto:tor-talk-boun...@lists.torproject.org] On Behalf Of Need Secure Mail Sent: Wednesday, August 8, 2018 12:28 PM To: tor-talk@lists.torproject.org Subject: Re: [tor-talk] HSTS forbids "Add an exception" (also, does request URI leak?) On August 8, 2018 1:57 PM, Matthew Finkel wrote: > Right. This is the recommendation in the RFC [0]. It would be > counter-productive if the webserver informed the browser that the > website should only be loaded over a secure connection, and then the > user was given the option of ignore that. That would completely defeat > the purpose of HSTS. > > [0] https://tools.ietf.org/html/rfc6797#page-30 > Section 12.1 Thanks, I was already quite familiar with the RFC. I know its rationale. But it is an absolute rule that *I* get the final word on what my machine does. That is why I run open-source software, after all. I understand that most users essentially must be protected from their own bad decisions when faced with clickthrough warnings. I have read the pertinent research. It's fine that the easy-clickthrough GUI button is removed by HSTS. However, if *I* desire to "completely defeat the purpose of HSTS", then I shall do so, and my user-agent shall obey me. I understand exactly how HSTS works, and I know the implications of overriding it. >> This error made me realize that Tor Browser/Firefox must load at >> least the response HTTP headers before displaying the certificate >> error message. I did not realize this! I reasonably assumed that it >> had simply refused to complete the TLS handshake. No TLS connection, no way >> to know about HSTS. > > Why? There are three(?) options here: > > 1) The domain is preloaded in the browser's STS list, so it knows > ahead of time if that site should only use TLS or not. Although I did not check the browser's preload list, I have observed this on a relatively obscure domain very unlikely to be on it... > 2) The domain is not in the preloaded list, so the browser learns > about the website setting HSTS on its first successful TLS connection > and HTTP request. ...as to which I had never yet successfully made a TLS connection in that temporary VM, with a fresh Tor Browser instance which had never before visited *any* sites... > 3) The user previously loaded the site and the browser cached a STS > value for that domain. ...and thus of course, could not save anything from previous loads of the site. My whole browsing setup is amnesiac. I literally use a new VM with "new" Tor Browser installation for each and every browsing session. No cached STS value! >> Scary. How much does Tor Browser actually load over an >> *unauthenticated* connection? Most importantly, I am curious, does it >> leak the request URI path (including query string parameters) this >> way? Or does it do something like a `HEAD /` to specifically check >> for HSTS? No request headers, no response headers, no way to know >> about HSTS. Spies running sslstrip may be interested in that. > > No? This was one of the main goals of HSTS. It should prevent SSL > stripping (for some definitions of prevent). Key phrase: "for some definitions of prevent". Inductive reasoning: For a site not in the STS preload list and never before visited, the only means for the user-agent to know about STS is to receive an HTTP response header. The only means to receive an HTTP response header, is to send HTTP request headers. Assume that the browser does not make an HTTP request. How does it know that the site uses STS? The HTTP request headers themselves may be useful to spies. Without the request headers, a network evesdropper only knows the hostname of the request (via SNI, RFC 6066). With the request headers: 0. The request path informs the evesdropper about which news articles I am reading on www.newspaper.dom, which people I communicate with on www.socialmedia.dom, etc. 1. Query string parameters, if any, are exposed. On many sites, this can be a severe privacy problem. On some (badly-designed) sites, it can also be a security issue. 2. Some browser fingerprint information is exposed. This is a lesser issue with Tor Browser requests from a Tor exit; any tcp/443 traffic from a Tor exit can be presumed Tor Browser unless demonstrated otherwise. However, the principle with TLS should be: Do not expose anything on the network which is not exposed by TLS itself (or lower network layers). The most sensitive information is the request path. If the user-agent wishes to ascertain HSTS status upon a certificate validation error, it could perform a fake `HEAD /` request as I suggested upthread; indeed, it is only means of receiving an HSTS response header without potentially leaking the request path to an sslstripper. I do not know if Tor Browser already does this, and have not checked too carefully. I did glance back through RFC 6797's
Re: [tor-talk] HSTS forbids "Add an exception" (also, does request URI leak?)
On Wed, Aug 08, 2018 at 04:27:33PM +, Need Secure Mail wrote: > On August 8, 2018 1:57 PM, Matthew Finkel wrote: > > > Right. This is the recommendation in the RFC [0]. It would be > > counter-productive if the webserver informed the browser that the > > website should only be loaded over a secure connection, and then the > > user was given the option of ignore that. That would completely defeat > > the purpose of HSTS. > > > > [0] https://tools.ietf.org/html/rfc6797#page-30 > > Section 12.1 > > Thanks, I was already quite familiar with the RFC. I know its rationale. > > But it is an absolute rule that *I* get the final word on what my machine > does. That is why I run open-source software, after all. I understand that > most users essentially must be protected from their own bad decisions when > faced with clickthrough warnings. I have read the pertinent research. It's > fine that the easy-clickthrough GUI button is removed by HSTS. However, > if *I* desire to "completely defeat the purpose of HSTS", then I shall > do so, and my user-agent shall obey me. I understand exactly how HSTS > works, and I know the implications of overriding it. Please consider opening a bug with Mozilla for this. > > >> This error made me realize that Tor Browser/Firefox must load at least the > >> response HTTP headers before displaying the certificate error message. I > >> did not realize this! I reasonably assumed that it had simply refused to > >> complete the TLS handshake. No TLS connection, no way to know about HSTS. > > > > Why? There are three(?) options here: > > > > 1) The domain is preloaded in the browser's STS list, so it knows ahead > > of time if that site should only use TLS or not. > > Although I did not check the browser's preload list, I have observed > this on a relatively obscure domain very unlikely to be on it... Full list (for latest stable Tor Browser): https://gitweb.torproject.org/tor-browser.git/plain/security/manager/ssl/nsSTSPreloadList.inc?h=tor-browser-52.9.0esr-7.5-2 I don't have a good explanation for why you experienced this. [snip] > >> Scary. How much does Tor Browser actually load over an *unauthenticated* > >> connection? Most importantly, I am curious, does it leak the request > >> URI path (including query string parameters) this way? Or does it do > >> something like a `HEAD /` to specifically check for HSTS? No request > >> headers, no response headers, no way to know about HSTS. Spies running > >> sslstrip may be interested in that. > > > > No? This was one of the main goals of HSTS. It should prevent SSL > > stripping (for some definitions of prevent). > > Key phrase: "for some definitions of prevent". > > Inductive reasoning: For a site not in the STS preload list and never > before visited, the only means for the user-agent to know about STS is > to receive an HTTP response header. The only means to receive an HTTP > response header, is to send HTTP request headers. Assume that the browser > does not make an HTTP request. How does it know that the site uses STS? Correct. HSTS is a TOFU protocol, and it only takes effect on the second connection. From what I see in the Firefox code, the HSTS value is only cached after the HTTP response header is parsed. The next time the website is requested, Firefox checks the cache for a STS entry and forces TLS if an entry exists. Unless the browser includes the domain in the STS preload list, you shouldn't experience a problem loading a broken-TLS-configured website until the second request. But, maybe I missed something. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor-friendly, Bitcoin-friendly paid e-mail
On 8/8/2018 6:22 PM, Need Secure Mail wrote: Grizzled long-time Tor user here. I seek basic, reliable POP/IMAP/SMTP service with an option to use my own domain (to avoid lock-in with a provider), from a well-established provider who will not likely disappear *and* will never block my account for Tor logins, demand selfies with gov-id, etc. I am willing to pay a reasonable amount, because TANSTAAFL. I will NOT use credit cards, Paypal, or any such horrible monstrosity. Here is what I found so far. The following list is not in any way intended to be comprehensive. I've spent many hours searching the web, winnowing things down. I invite discussion. Observed TLSA (DANE) implementation status is listed, due to this being (unfortunately) the only standardized means to prevent STARTTLS downgrade attacks. When multiple currency-of-account options are offered, I list prices in the currency most favorable to the user at current exchange rates. Much as I can, I try to list the effective *actual* cost to the user, per month, if paid on an annual basis. This may differ from the advertised price. I am not affiliated with any of the below-listed companies; I receive no compensation if you sign up for any of them. Without further ado, here is my current shortlist: # https://mailbox.org/en/ - Effective price: €1.01/month (€1 + 1% Bitpay fee; prepay annually) - By: Heinlein Support GmbH - Jurisdiction: Germany (EU; Fourteen Eyes) - .onion site (POP3/IMAP/SMTP/XMPP; no web): kqiafglit242fygz.onion - Working DNSSEC/TLSA: https://dane.sys4.de/smtp/mailbox.org I found this through the Tor trac,[0] which is probably the very best advertising for them. Everything looks pretty good from a technical perspective. Price is reasonable. I like how the signup form asks for a name, but explicitly says it does not need to be your "real name". Though I have not yet tested this, it looks like you can attach one domain to the account for each alias; and the €1/month account provides three aliases. This could make a cost-effective home/work identity solution for an individual with a limited budget. A 30-day trial account limits features, but allows POP/IMAP/SMTP access. I will give this a spin, and pay them money if it works out. I do wish that they were not in a Fourteen Eyes country. [0] https://trac.torproject.org/projects/tor/wiki/org/projects/WeSupportTor # https://mailfence.com/ - Effective price: About $3.25/month (prepay annually) - By: ContactOffice Group sa - Jurisdiction: Belgium (EU; Fourteen Eyes) - .onion site: Promised, but not actually existing.[1] - No DNSSEC, thus no TLSA: https://dane.sys4.de/smtp/mailfence.com Before I found mailbox.org, I signed up for this and almost paid for an account. For the most inexpensive account, I was offered payment options of €2.50/month or $2.77/month, both paid annually. That exchange rate is moderately favorable to USD; so I selected $2.77/month. *Then*, I saw the amount of Bitcoin they demanded: 0.005142968 BTC, allegedly for $33.30. That works out to a Bitcoin exchange rate of $6474.86/BTC. At that exact moment, my desktop ticker was showing an average exchange rate of $7591.24/BTC. Thus, they offered me a HORRIBLE exchange rate, almost 15% under market! This makes the effective account price $39.04/year, or $3.25/month. How many people use a desktop calculator to check the exchange rate? Well, you need to wake up pretty early to fool me. Mailfence's free accounts do not offer POP/IMAP/SMTP access; so I am unable to fully test their services without paying. I prefer Mailbox's arrangement with a time-limited trial account. I am totally uninterested in webmail; how am I supposed to test a service without POP/IMAP/SMTP access? [1] https://blog.mailfence.com/send-email-anonymously-mailfence-tor/ Text: "Note: we also plan to release an onion domain for Mailfence in the future." Comments: "Yes, we do plan to provide a Tor hidden service. However, this currently is not in our priority list." (2017-02-27) # https://protonmail.com/ - Effective price: $4.00/month (prepaid annually) - By: Proton Technologies, SA - Jurisdiction: Switzerland - Standard PGP, standard algorithms: No homebrew crypto! - Can communicate with GPG users. - POP/IMAP/SMTP access requires "Bridge" proxy software. - .onion site (mail login only): https://protonirockerxow.onion/login - DNSSEC, but no DANE/TLSA: https://dane.sys4.de/smtp/protonmail.ch Ok, everybody knows Protonmail. As a longtime PGP/GPG user, I love Protonmail 3.14 because I can direct n00bs to it as a user-friendly PGP mail solution[2] which Just Works. However, it does not meet *my* needs. I need my local GPG. I need a dropbox which can be accessed through POP/IMAP and polled from my crontab, with sending via SMTP. No web browsers, no "Bridge". Also: The price is reasonable for the full-featured service they offer; however, it is way too high for the services I myself need. If Protonmail offered a no-frills POP box on their Swiss
Re: [tor-talk] Tor-friendly, Bitcoin-friendly paid e-mail
gandi.net https://www.reddit.com/r/emailprivacy/ https://www.reddit.com/r/onions/ deepdotweb search: email tor onion Etc. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor-friendly, Bitcoin-friendly paid e-mail
vfemail.net Probably many others still on bitcoin.it and other wikis. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] HSTS forbids "Add an exception" (also, does request URI leak?)
On August 8, 2018 1:57 PM, Matthew Finkel wrote: > Right. This is the recommendation in the RFC [0]. It would be > counter-productive if the webserver informed the browser that the > website should only be loaded over a secure connection, and then the > user was given the option of ignore that. That would completely defeat > the purpose of HSTS. > > [0] https://tools.ietf.org/html/rfc6797#page-30 > Section 12.1 Thanks, I was already quite familiar with the RFC. I know its rationale. But it is an absolute rule that *I* get the final word on what my machine does. That is why I run open-source software, after all. I understand that most users essentially must be protected from their own bad decisions when faced with clickthrough warnings. I have read the pertinent research. It's fine that the easy-clickthrough GUI button is removed by HSTS. However, if *I* desire to "completely defeat the purpose of HSTS", then I shall do so, and my user-agent shall obey me. I understand exactly how HSTS works, and I know the implications of overriding it. >> This error made me realize that Tor Browser/Firefox must load at least the >> response HTTP headers before displaying the certificate error message. I >> did not realize this! I reasonably assumed that it had simply refused to >> complete the TLS handshake. No TLS connection, no way to know about HSTS. > > Why? There are three(?) options here: > > 1) The domain is preloaded in the browser's STS list, so it knows ahead > of time if that site should only use TLS or not. Although I did not check the browser's preload list, I have observed this on a relatively obscure domain very unlikely to be on it... > 2) The domain is not in the preloaded list, so the browser learns about > the website setting HSTS on its first successful TLS connection and HTTP > request. ...as to which I had never yet successfully made a TLS connection in that temporary VM, with a fresh Tor Browser instance which had never before visited *any* sites... > 3) The user previously loaded the site and the browser cached a STS > value for that domain. ...and thus of course, could not save anything from previous loads of the site. My whole browsing setup is amnesiac. I literally use a new VM with "new" Tor Browser installation for each and every browsing session. No cached STS value! >> Scary. How much does Tor Browser actually load over an *unauthenticated* >> connection? Most importantly, I am curious, does it leak the request >> URI path (including query string parameters) this way? Or does it do >> something like a `HEAD /` to specifically check for HSTS? No request >> headers, no response headers, no way to know about HSTS. Spies running >> sslstrip may be interested in that. > > No? This was one of the main goals of HSTS. It should prevent SSL > stripping (for some definitions of prevent). Key phrase: "for some definitions of prevent". Inductive reasoning: For a site not in the STS preload list and never before visited, the only means for the user-agent to know about STS is to receive an HTTP response header. The only means to receive an HTTP response header, is to send HTTP request headers. Assume that the browser does not make an HTTP request. How does it know that the site uses STS? The HTTP request headers themselves may be useful to spies. Without the request headers, a network evesdropper only knows the hostname of the request (via SNI, RFC 6066). With the request headers: 0. The request path informs the evesdropper about which news articles I am reading on www.newspaper.dom, which people I communicate with on www.socialmedia.dom, etc. 1. Query string parameters, if any, are exposed. On many sites, this can be a severe privacy problem. On some (badly-designed) sites, it can also be a security issue. 2. Some browser fingerprint information is exposed. This is a lesser issue with Tor Browser requests from a Tor exit; any tcp/443 traffic from a Tor exit can be presumed Tor Browser unless demonstrated otherwise. However, the principle with TLS should be: Do not expose anything on the network which is not exposed by TLS itself (or lower network layers). The most sensitive information is the request path. If the user-agent wishes to ascertain HSTS status upon a certificate validation error, it could perform a fake `HEAD /` request as I suggested upthread; indeed, it is only means of receiving an HSTS response header without potentially leaking the request path to an sslstripper. I do not know if Tor Browser already does this, and have not checked too carefully. I did glance back through RFC 6797's advice to implementors, and saw nothing about this issue. > I'm also not sure if you're referring to public key pinning, as well. No, I am referring only to HSTS. I have read both RFCs. I would not confuse them. I would *not* override a HPKP pin, unless I saw it very well-documented that a site had committed "pin-suicide". My interest in this thread is overriding HSTS, due to the issue
[tor-talk] Tor-friendly, Bitcoin-friendly paid e-mail
Grizzled long-time Tor user here. I seek basic, reliable POP/IMAP/SMTP service with an option to use my own domain (to avoid lock-in with a provider), from a well-established provider who will not likely disappear *and* will never block my account for Tor logins, demand selfies with gov-id, etc. I am willing to pay a reasonable amount, because TANSTAAFL. I will NOT use credit cards, Paypal, or any such horrible monstrosity. Here is what I found so far. The following list is not in any way intended to be comprehensive. I've spent many hours searching the web, winnowing things down. I invite discussion. Observed TLSA (DANE) implementation status is listed, due to this being (unfortunately) the only standardized means to prevent STARTTLS downgrade attacks. When multiple currency-of-account options are offered, I list prices in the currency most favorable to the user at current exchange rates. Much as I can, I try to list the effective *actual* cost to the user, per month, if paid on an annual basis. This may differ from the advertised price. I am not affiliated with any of the below-listed companies; I receive no compensation if you sign up for any of them. Without further ado, here is my current shortlist: # https://mailbox.org/en/ - Effective price: €1.01/month (€1 + 1% Bitpay fee; prepay annually) - By: Heinlein Support GmbH - Jurisdiction: Germany (EU; Fourteen Eyes) - .onion site (POP3/IMAP/SMTP/XMPP; no web): kqiafglit242fygz.onion - Working DNSSEC/TLSA: https://dane.sys4.de/smtp/mailbox.org I found this through the Tor trac,[0] which is probably the very best advertising for them. Everything looks pretty good from a technical perspective. Price is reasonable. I like how the signup form asks for a name, but explicitly says it does not need to be your "real name". Though I have not yet tested this, it looks like you can attach one domain to the account for each alias; and the €1/month account provides three aliases. This could make a cost-effective home/work identity solution for an individual with a limited budget. A 30-day trial account limits features, but allows POP/IMAP/SMTP access. I will give this a spin, and pay them money if it works out. I do wish that they were not in a Fourteen Eyes country. [0] https://trac.torproject.org/projects/tor/wiki/org/projects/WeSupportTor # https://mailfence.com/ - Effective price: About $3.25/month (prepay annually) - By: ContactOffice Group sa - Jurisdiction: Belgium (EU; Fourteen Eyes) - .onion site: Promised, but not actually existing.[1] - No DNSSEC, thus no TLSA: https://dane.sys4.de/smtp/mailfence.com Before I found mailbox.org, I signed up for this and almost paid for an account. For the most inexpensive account, I was offered payment options of €2.50/month or $2.77/month, both paid annually. That exchange rate is moderately favorable to USD; so I selected $2.77/month. *Then*, I saw the amount of Bitcoin they demanded: 0.005142968 BTC, allegedly for $33.30. That works out to a Bitcoin exchange rate of $6474.86/BTC. At that exact moment, my desktop ticker was showing an average exchange rate of $7591.24/BTC. Thus, they offered me a HORRIBLE exchange rate, almost 15% under market! This makes the effective account price $39.04/year, or $3.25/month. How many people use a desktop calculator to check the exchange rate? Well, you need to wake up pretty early to fool me. Mailfence's free accounts do not offer POP/IMAP/SMTP access; so I am unable to fully test their services without paying. I prefer Mailbox's arrangement with a time-limited trial account. I am totally uninterested in webmail; how am I supposed to test a service without POP/IMAP/SMTP access? [1] https://blog.mailfence.com/send-email-anonymously-mailfence-tor/ Text: "Note: we also plan to release an onion domain for Mailfence in the future." Comments: "Yes, we do plan to provide a Tor hidden service. However, this currently is not in our priority list." (2017-02-27) # https://protonmail.com/ - Effective price: $4.00/month (prepaid annually) - By: Proton Technologies, SA - Jurisdiction: Switzerland - Standard PGP, standard algorithms: No homebrew crypto! - Can communicate with GPG users. - POP/IMAP/SMTP access requires "Bridge" proxy software. - .onion site (mail login only): https://protonirockerxow.onion/login - DNSSEC, but no DANE/TLSA: https://dane.sys4.de/smtp/protonmail.ch Ok, everybody knows Protonmail. As a longtime PGP/GPG user, I love Protonmail 3.14 because I can direct n00bs to it as a user-friendly PGP mail solution[2] which Just Works. However, it does not meet *my* needs. I need my local GPG. I need a dropbox which can be accessed through POP/IMAP and polled from my crontab, with sending via SMTP. No web browsers, no "Bridge". Also: The price is reasonable for the full-featured service they offer; however, it is way too high for the services I myself need. If Protonmail offered a no-frills POP box on their Swiss servers for $2/month, or even $3/month for a
Re: [tor-talk] HSTS forbids "Add an exception" (also, does request URI leak?)
On Wed, Aug 08, 2018 at 10:59:23AM +, Need Secure Mail wrote: > On August 7, 2018 11:14 PM, nusenu wrote: > >> did you notice the non-HSTS/HSTS distinction when trying to add an > >> exception? > > On August 8, 2018 1:51 AM, grarpamp wrote: > > If there is, would have to look closer, thx. > > The following is to help searchers who rammed their heads into this > problem, as I did when accessing clearnet version of a rather popular > .onion (LE cert). > > Firefox/Tor Browser disallows adding an exception. The "add an exception" > button does not even appear! It gives the error message: > > "This site uses HTTP Strict Transport Security (HSTS) to specify that > Tor Browser may only connect to it securely. As a result, it is not > possible to add an exception for this certificate." Right. This is the recommendation in the RFC [0]. It would be counter-productive if the webserver informed the browser that the website should only be loaded over a secure connection, and then the user was given the option of ignore that. That would completely defeat the purpose of HSTS. [0] https://tools.ietf.org/html/rfc6797#page-30 Section 12.1 [snip] > > > Topic drift observation: > > This error made me realize that Tor Browser/Firefox must load at least the > response HTTP headers before displaying the certificate error message. I > did not realize this! I reasonably assumed that it had simply refused to > complete the TLS handshake. No TLS connection, no way to know about HSTS. Why? There are three(?) options here: 1) The domain is preloaded in the browser's STS list, so it knows ahead of time if that site should only use TLS or not. If it is in the preloaded list, then the browser establishes a TLS connection as the first step. If this fails, then none of the HTTP Request was leaked. If the TLS connection fails, then the user is shown an error page and cannot add an exception. 2) The domain is not in the preloaded list, so the browser learns about the website setting HSTS on its first successful TLS connection and HTTP request. This would potentially leak the user's entire request to a MITM but this (HSTS) would not detect a MITM either. The MITM (or malicious endpoint) would only be detected if they served an invalid certificate chain for the domain name. The HSTS header would only prevent the user from loading the website over an insecure HTTP connection in the future. 3) The user previously loaded the site and the browser cached a STS value for that domain. If the user tries visiting the website again, except this time they request an insecure connection, then the browser will rewrite the URI so it uses TLS port 443 (by default), and then it will initiate the TLS connection. There isn't any information leaked before the TLS handshake. Furthermore, if the server and browser cannot negotiate a valid TLS connection (because the certificate-chain is invalid, or the ciphersuites don't intersect), then the user is presented with an error message which they cannot override and add an exception (as you experienced). > > Scary. How much does Tor Browser actually load over an *unauthenticated* > connection? Most importantly, I am curious, does it leak the request > URI path (including query string parameters) this way? Or does it do > something like a `HEAD /` to specifically check for HSTS? No request > headers, no response headers, no way to know about HSTS. Spies running > sslstrip may be interested in that. No? This was one of the main goals of HSTS. It should prevent SSL stripping (for some definitions of prevent). I'm also not sure if you're referring to public key pinning, as well. Where the website can specify the exact hash of its public key in the HTTP headers. That is another topic, and that relies on Trust-On-First-Use, as well. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] HSTS forbids "Add an exception" (also, does request URI leak?)
On August 7, 2018 11:14 PM, nusenu wrote: >> did you notice the non-HSTS/HSTS distinction when trying to add an exception? On August 8, 2018 1:51 AM, grarpamp wrote: > If there is, would have to look closer, thx. The following is to help searchers who rammed their heads into this problem, as I did when accessing clearnet version of a rather popular .onion (LE cert). Firefox/Tor Browser disallows adding an exception. The "add an exception" button does not even appear! It gives the error message: "This site uses HTTP Strict Transport Security (HSTS) to specify that Tor Browser may only connect to it securely. As a result, it is not possible to add an exception for this certificate." Workaround FOR ADVANCED SECURITY GURUS ONLY -- WARNING, DANGER, YOU CAN BREAK YOUR SECURITY IF YOU DO NOT KNOW WHAT YOU ARE DOING -- create prefs integer before visiting the broken website: test.currentTimeOffsetSeconds 11491200 Instructions given here are intentionally opaque; if you don't know what that means, don't try it. Doing this is NOT RECOMMENDED. I myself would NEVER do this unless either I verified the certificate fingerprint by out-of-band means, or observed the same fingerprint through many different random exits. If you don't understand what this means, please do not try to override HSTS. You will get ruined by a BadExit. Evil h4x0rs with sslstrip will steal your identity, dox you on the scary darknets, and put sugar in your gas tank. Instead of overriding security features, tell the server admin of the broken website to fix his problem by adding intermediate certificate to chain in webserver config. Topic drift observation: This error made me realize that Tor Browser/Firefox must load at least the response HTTP headers before displaying the certificate error message. I did not realize this! I reasonably assumed that it had simply refused to complete the TLS handshake. No TLS connection, no way to know about HSTS. Scary. How much does Tor Browser actually load over an *unauthenticated* connection? Most importantly, I am curious, does it leak the request URI path (including query string parameters) this way? Or does it do something like a `HEAD /` to specifically check for HSTS? No request headers, no response headers, no way to know about HSTS. Spies running sslstrip may be interested in that. Sent with ProtonMail Secure Email. signature.asc Description: OpenPGP digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
