-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/09/2015 06:20 PM, Tomasz Sterna wrote:
> Dnia 2015-11-09, pon o godzinie 17:33 -0500, Travis Burtrum pisze:
>> That seems like a ridiculous question to me. If not, why even bother
>> with STARTTLS/TLS in the first place? It *could* be used for
Dnia 2015-11-09, pon o godzinie 17:33 -0500, Travis Burtrum pisze:
> That seems like a ridiculous question to me. If not, why even bother
> with STARTTLS/TLS in the first place? It *could* be used for
> circumventing security policies after all.
Your own words from the XEP:
"at least equal and p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/09/2015 05:22 PM, Tomasz Sterna wrote:
> Dnia 2015-11-09, pon o godzinie 15:29 -0500, Travis Burtrum pisze:
>> accepting raw xmpp along with https on 443 is not a good option
>> because it's obviously xmpp and can be trivially blocked
>
> Sho
On 9 November 2015 at 19:42, James Cloos wrote:
> > "DC" == Dave Cridland writes:
>
> DC> No, that's not true. That's only true if the TLSA records provide a
> DC> specific EE cert; that is, Certificate Usage 3. All other cases involve
> DC> path validation and name checks.
>
> Even with typ
Dnia 2015-11-09, pon o godzinie 15:29 -0500, Travis Burtrum pisze:
> accepting raw xmpp along with https on 443 is not a good option
> because it's obviously xmpp and can be trivially blocked
Should XSF work on technologies targetted on circumventing security
policies?
And if so, what about block
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/09/2015 02:46 PM, Tomasz Sterna wrote:
> Isn't smart proxy like sslh[1] better suited for the use case?
>
>
> [1] http://www.rutschle.net/tech/sslh.shtml
Which use case? I actually do use sslh on my port 443, because I
wrote a patch to let
Dnia 2015-11-05, czw o godzinie 12:45 -0500, Travis Burtrum pisze:
> Rendered version can be found at
> https://burtrum.org/xeps/tls-srv.html
Isn't smart proxy like sslh[1] better suited for the use case?
[1] http://www.rutschle.net/tech/sslh.shtml
--
/o__
(_<^' Love sometimes expresses its
> "DC" == Dave Cridland writes:
DC> No, that's not true. That's only true if the TLSA records provide a
DC> specific EE cert; that is, Certificate Usage 3. All other cases involve
DC> path validation and name checks.
Even with types 0, 1 or 2, the point is that the machine name is always
use
On 9 November 2015 at 16:16, James Cloos wrote:
> > "DC" == Dave Cridland writes:
>
> >> The service name is only supposed to be relevant iff ( the dns lookups
> are
> >> not secure OR there is no TLSA ) .
>
> DC> Where do you get this assertion from?
>
> DC> I would have thought that the re
> "DC" == Dave Cridland writes:
>> The service name is only supposed to be relevant iff ( the dns lookups are
>> not secure OR there is no TLSA ) .
DC> Where do you get this assertion from?
DC> I would have thought that the reverse is true - the user-supplied
DC> identifier is always releva
On 9 November 2015 at 15:51, James Cloos wrote:
> The service name is only supposed to be relevant iff ( the dns lookups are
> not secure OR there is no TLSA ) .
>
>
Where do you get this assertion from?
I would have thought that the reverse is true - the user-supplied
identifier is always relev
> "KA" == Kim Alvefur writes:
KA> I was actually working on that the other day. Support for SNI doesn't
KA> make it easier if the SNI name does not match any local service names,
KA> only SRV targets, which could be anything.
The SRV target would be an A or name, that should be a hostn
12 matches
Mail list logo
