Anybody know how https *really* works? I didn't think so

[Ari Silverstein]

On Mon, 1 Nov 2010 10:08:49 -0700 (PDT), RayLopez99 wrote:

> That's the second time I've used please in this post
> and twice too many.

See what I mean? Pants on fire there, assclown.
--
http://tr.im/1fa3

[FromTheRafters]

"RayLopez99" <raylopez88@gmail.com> wrote in message
news:10194b0e-7873-4931-b5ec-d8d7d99f939d@y23g2000yqd.googlegroups.com...
On Nov 1, 4:13 pm, "FromTheRafters" <erra...@nomail.afraid.org> wrote:

>
> >> Does this make sense?
>
> > No. Private keys are never shared with anyone.
>
> > Further reading:
> >http://www.ourshop.com/resources/ssl.html
>
> It may take a while, but eventually he will understand that the data
> is
> "covered" only in transit just as with TPM supported disk encryption
> it
> is only covered at rest.

Explain please in simple words. You are saying encryption of https
data is only done in transit? Why/how? To be more explicit: C
(client) --> S (intermediary) --> Z (endpoint/host server): you are
saying encryption is only at the "-->" in between the points, C, S and
Z? That is, at the servers C,S,Z you can read the data packets in
plaintext, but when they transmit the data stream they become
encrypted ciphertext?

***
The client and server have a trust relationship, they agree on a keyset
and the data is encrypted by the client, sent out on the wire, received
by the server, and decrypted by the key. If it needs to do it again (not
the final destination), another trust relationship is set up btween the
server and the next step and the process may be repeated (new
relationships, new keys, no transitive trust). The idea was to have the
data covered so that sniffing or otherwise capturing packets enroute
would not have value to the interloper (the encryption security is as
good as the key management - if the interloper (you don't have a trust
relationship with) doesn't have the key, he cannot convert the
ciphertext to plaintext.

You are *trusting* all of the SSL capable servers with your data unless
you "cover" your data for the entire source to destination trip.
***

If so, this does make Jason Keats explanation work, but I would be
very surprised if this is so. Why would anybody design an algorithm
that decrypts as soon as it reaches a server?

***
Those whom are only concerned with the security (integrity) of the
point-to-point communications.

Think of the old can-to-can voice communication, and someone
eavesdropping with a tap on the string. You still want to be able to
speak into one end and hear from the other, but you want the
eavesdropper to get nothing intelligible. If your can-to-can connection
is only one part of a relay communication network, you wouldn't be
concerned about the relay personnel actually having access to that
information uncovered. If you were concerned about that, then end-to-end
coverage is what you really want.
***

[Jason Keats]

RayLopez99 wrote:
> On Nov 1, 4:13 pm, "FromTheRafters"<erra...@nomail.afraid.org> wrote:
>
>>
>>>> Does this make sense?
>>
>>> No. Private keys are never shared with anyone.
>>
>>> Further reading:
>>> http://www.ourshop.com/resources/ssl.html
>>
>> It may take a while, but eventually he will understand that the data is
>> "covered" only in transit just as with TPM supported disk encryption it
>> is only covered at rest.
>
> Explain please in simple words. You are saying encryption of https
> data is only done in transit? Why/how? To be more explicit: C
> (client) --> S (intermediary) --> Z (endpoint/host server): you are
> saying encryption is only at the "-->" in between the points, C, S and
> Z? That is, at the servers C,S,Z you can read the data packets in
> plaintext, but when they transmit the data stream they become
> encrypted ciphertext?

Yes, that's correct - because C used S's URL, not Z's.

> If so, this does make Jason Keats explanation work, but I would be
> very surprised if this is so. Why would anybody design an algorithm
> that decrypts as soon as it reaches a server?

The protocol doesn't decrypt as soon as soon as it reaches _any_ server,
only when it reaches _the_ server addressed in the URL.

[RayLopez99]

On Nov 2, 3:10*am, "FromTheRafters" <erra...@nomail.afraid.org> wrote:
> "RayLopez99" <raylope...@gmail.com> wrote in message
>
> news:10194b0e-7873-4931-b5ec-d8d7d99f939d@y23g2000yqd.googlegroups.com...
> On Nov 1, 4:13 pm, "FromTheRafters" <erra...@nomail.afraid.org> wrote:
>
>
>
> > >> Does this make sense?
>
> > > No. Private keys are never shared with anyone.
>
> > > Further reading:
> > >http://www.ourshop.com/resources/ssl.html
>
> > It may take a while, but eventually he will understand that the data
> > is
> > "covered" only in transit just as with TPM supported disk encryption
> > it
> > is only covered at rest.
>
> Explain please in simple words. *You are saying encryption of https
> data is only done in transit? *Why/how? *To be more explicit: *C
> (client) --> S (intermediary) --> Z (endpoint/host server): *you are
> saying encryption is only at the "-->" in between the points, C, S and
> Z? *That is, at the servers C,S,Z you can read the data packets in
> plaintext, but when they transmit the data stream they become
> encrypted ciphertext?
>
> ***
> The client and server have a trust relationship, they agree on a keyset
> and the data is encrypted by the client, sent out on the wire, received
> by the server, and decrypted by the key. If it needs to do it again (not
> the final destination), another trust relationship is set up btween the
> server and the next step and the process may be repeated (new
> relationships, new keys, no transitive trust). The idea was to have the
> data covered so that sniffing or otherwise capturing packets enroute
> would not have value to the interloper (the encryption security is as
> good as the key management - if the interloper (you don't have a trust
> relationship with) doesn't have the key, he cannot convert the
> ciphertext to plaintext.
>

Thanks. OK, but who sets up the 'new keys', 'new relationships'? It
has to be done by somebody using new SSL certificates, not the
original one used by C?

Here is where I'm going: C wants to send to Z. It types in Z's URL
using an SSL certificate. By the nature of the internet, inbetween C
and Z there are always other servers that act as relays, call one of
them 'S'. Is it possible for them to use 'new keys', 'new
relationships' that would compromise the message from C to Z? Unknown
to C? I don't think so--or I can't see how. That is, C would have to
send a message to 'S', not 'Z'. But at that point, we are arguing
over semantics--'S' now *is* 'Z'! Of course if S wants to send to Z,
that will mean S can read the message--but that's just plain stupid
semantics.

Please explain if it's possible for C to send to Z, then, if there's
an intermediate SOAP server S, unknown to C (maybe not unknown, but
perhaps unsuspected for a security risk) whether S can decrypt the
message if C has typed in Z's URL. Unless--and maybe this is
possible--C types in Z's URL but the program--behind the scenes--
changes Z's URL to S! Why would it do that--can it do that?

RL

[RayLopez99]

On Nov 2, 3:33*am, Jason Keats <jke...@melbpcDeleteThis.org.au> wrote:

> > Explain please in simple words. *You are saying encryption of https
> > data is only done in transit? *Why/how? *To be more explicit: *C
> > (client) --> *S (intermediary) --> *Z (endpoint/host server): *you are
> > saying encryption is only at the "-->" in between the points, C, S and
> > Z? *That is, at the servers C,S,Z you can read the data packets in
> > plaintext, but when they transmit the data stream they become
> > encrypted ciphertext?
>
> Yes, that's correct - because C used S's URL, not Z's.
>
> > If so, this does make Jason Keats explanation work, but I would be
> > very surprised if this is so. *Why would anybody design an algorithm
> > that decrypts as soon as it reaches a server?
>
> The protocol doesn't decrypt as soon as soon as it reaches _any_ server,
> only when it reaches _the_ server addressed in the URL.

My same question to you as to FromTheRafters (repeated below). I
don't see how--even accepting your explanation--if C uses Z's URL this
can happen--unless, C uses S's URL rather than Z 'without knowing
it' (that is, it is substituted by either the program or by the HTTPS
public key mechanism itself unknown to C). Does this 'unknown' use
happen in practice? Is this the infamous "Cross-site scripting (XSS)"
attack? Is this how S becomes Z?

RL

> ***
> The client and server have a trust relationship, they agree on a keyset
> and the data is encrypted by the client, sent out on the wire, received
> by the server, and decrypted by the key. If it needs to do it again (not
> the final destination), another trust relationship is set up btween the
> server and the next step and the process may be repeated (new
> relationships, new keys, no transitive trust). The idea was to have the
> data covered so that sniffing or otherwise capturing packets enroute
> would not have value to the interloper (the encryption security is as
> good as the key management - if the interloper (you don't have a trust
> relationship with) doesn't have the key, he cannot convert the
> ciphertext to plaintext.
>

Thanks. OK, but who sets up the 'new keys', 'new relationships'? It
has to be done by somebody using new SSL certificates, not the
original one used by C?

Here is where I'm going: C wants to send to Z. It types in Z's URL
using an SSL certificate. By the nature of the internet, inbetween C
and Z there are always other servers that act as relays, call one of
them 'S'. Is it possible for them to use 'new keys', 'new
relationships' that would compromise the message from C to Z? Unknown
to C? I don't think so--or I can't see how. That is, C would have to
send a message to 'S', not 'Z'. But at that point, we are arguing
over semantics--'S' now *is* 'Z'! Of course if S wants to send to Z,
that will mean S can read the message--but that's just plain stupid
semantics.

Please explain if it's possible for C to send to Z, then, if there's
an intermediate SOAP server S, unknown to C (maybe not unknown, but
perhaps unsuspected for a security risk) whether S can decrypt the
message if C has typed in Z's URL. Unless--and maybe this is
possible--C types in Z's URL but the program--behind the scenes--
changes Z's URL to S! Why would it do that--can it do that?


RL

[unruh]

["Followup-To:" header set to alt.computer.security.]
On 2010-11-02, RayLopez99 <raylopez88@gmail.com> wrote:
> On Nov 2, 3:10?am, "FromTheRafters" <erra...@nomail.afraid.org> wrote:
>> "RayLopez99" <raylope...@gmail.com> wrote in message
....
> Please explain if it's possible for C to send to Z, then, if there's
> an intermediate SOAP server S, unknown to C (maybe not unknown, but
> perhaps unsuspected for a security risk) whether S can decrypt the
> message if C has typed in Z's URL. Unless--and maybe this is
> possible--C types in Z's URL but the program--behind the scenes--
> changes Z's URL to S! Why would it do that--can it do that?
Your system contacts Z and asks for a public key. It then checks the
signing authority of that public key against the set of signing
authorities it has in its list. If it checks out, it then uses Z's
public key to encrypt a random symmentric key, and encrypts the message with
that symmetric key, and sends the encrypted symmetric key and the
encrypted message out.
Thus any S would need to know Z's private key,

Now, if S could act as a man in the middle, and persuade your machine
that S's public key is really Z's public key, then of course S could
read your transmission. That is prevented by the "web of trust" -- the
fact that you trust the signing authority who stated that Z's key really
was Z's key. Of course if you do not have the signing authority's public
key in your system or S has persuaded you (or your distro) to put a bogus public key for
that signing authority into your system, the game is up.
>O
So no, without a lot of work, intermediate machines cannot read your SSL
stuff sent to Z, or you ignored the warning from your browser that it
did not know the signing authority for the key you are using.

> RL

[Jason Keats]

RayLopez99 wrote:
>
> Please explain if it's possible for C to send to Z, then, if there's
> an intermediate SOAP server S, unknown to C (maybe not unknown, but
> perhaps unsuspected for a security risk) whether S can decrypt the
> message if C has typed in Z's URL.

The answer is still no!

[RayLopez99]

On Nov 2, 12:03*pm, unruh <un...@wormhole.physics.ubc.ca> wrote:

>
> Your system contacts Z and asks for a public key. It then checks the
> signing authority of that public key against the set of signing
> authorities it has in its list. If it checks out, it then uses Z's
> public key to encrypt a random symmentric key, and encrypts the message with
> that symmetric key, and sends the encrypted symmetric key and the
> encrypted message out.
> Thus any S would need to know Z's private key, *
>
> Now, if S could act as *a man in the middle, and persuade *your machine
> that S's public key is really Z's public key, then of course S could
> read your transmission. That is prevented by the "web of trust" -- the
> fact that you trust the signing authority who stated that Z's key really
> was Z's key. Of course if you do not have the signing authority's public
> key in your system or S has persuaded you (or your distro) to put a boguspublic key for
> that signing authority into your system, the game is up.>O
>
> So no, without a lot of work, intermediate machines cannot read your SSL
> stuff sent to Z, or you ignored the warning from your browser that it
> did not know the signing authority for the key you are using.
>

Unruh--you are probably late to this thread. The issue here is not
spoofing so much as the statement by others in this thread that S (the
intermediary) *CAN* read your SSL stuff. How it does this is the
question.

One proposal (and I have yet to see this explicitly): for SSL
encrypted message routing to work, when involving intermediaries like
SOAP servers (like S in our A to S to Z transmission of a SSL
message), S the intermediary *must* be able to decrypt the message.
It contacts the relevant endpoint, Z, gets permission to decrypt, and
does decrypt. Then it routes the message using the headers
(unencrypted). Before it transmits the message, S will of course
encrypt it again, so while the message is in transit nobody can read
it. But S itself can (and must) read the message for the transmission
to work.

Can anybody confirm this? I've not seen this on the net, but it's a
logical inference from what I have seen.

RL

[RayLopez99]

On Nov 2, 2:29*pm, Jason Keats <jke...@melbpcDeleteThis.org.au> wrote:
> RayLopez99 wrote:
>
> > Please explain if it's possible for C to send to Z, then, if there's
> > an intermediate SOAP server S, unknown to C (maybe not unknown, but
> > perhaps unsuspected for a security risk) whether S can decrypt the
> > message if C has typed in Z's URL.
>
> The answer is still no!

Why? See my question to Unruh. Don't crap out now Jason, we are close
to the finish line and you've come so far! Future readers of this
thread, and it's novel as I've not seen this topic elsewhere, will
wonder what the answer is.

RL

keywords: SSL does not work, SSL does not encrypt, SSL is not safe,
TLS does not work, TLS is not safe, TLS does not encrypt, message
security not 100% not complete not guaranteed with SSL or TLS, people
can read your messages with SSL certificate or TLS certificates.

[RayLopez99]

On Nov 2, 12:03*pm, unruh <un...@wormhole.physics.ubc.ca> wrote:

>
> Now, if S could act as *a man in the middle, and persuade *your machine
> that S's public key is really Z's public key, then of course S could
> read your transmission. That is prevented by the "web of trust" -- the
> fact that you trust the signing authority who stated that Z's key really
> was Z's key. Of course if you do not have the signing authority's public
> key in your system or S has persuaded you (or your distro) to put a boguspublic key for
> that signing authority into your system, the game is up.>O
>
> So no, without a lot of work, intermediate machines cannot read your SSL
> stuff sent to Z, or you ignored the warning from your browser that it
> did not know the signing authority for the key you are using.
>

Not sure if my reply got through, so I'll try and paraphrase it again.

The issue is how S (C --> S --> Z) *can* read your SSL stuff. How?
Microsoft says it's possible (see the link and blurb earlier in this
thread).

One idea: S has permission to read and decrypt the SSL stuff from C
and/or Z--so it's not 'illegal'. My question: when does this happen?
Does it happen only in 'rare' cases where the program needs to use an
intermediary SOAP server like S to get some additional information
(such as a mashup, if you know how they work), or, does this happen
*everytime* there is a transmission using several connecting points
(servers) in between C and Z? This latter scenario is what scares
me. I can deal with mashups explicitly being given permission to
decrypt, but I cannot deal with every intermediary server being able
to decrypt a SSL or TLS message--but maybe this latter case is how in
fact things work.

RL

[RayLopez99]

On Nov 3, 1:54*pm, RayLopez99 <raylope...@gmail.com> wrote:
> On Nov 2, 2:29*pm, Jason Keats <jke...@melbpcDeleteThis.org.au> wrote:
>
> > RayLopez99 wrote:
>
> > > Please explain if it's possible for C to send to Z, then, if there's
> > > an intermediate SOAP server S, unknown to C (maybe not unknown, but
> > > perhaps unsuspected for a security risk) whether S can decrypt the
> > > message if C has typed in Z's URL.
>
> > The answer is still no!
>
> Why? *See my question to Unruh. Don't crap out now Jason, we are close
> to the finish line and you've come so far! *Future readers of this
> thread, and it's novel as I've not seen this topic elsewhere, will
> wonder what the answer is.
>
> RL
>
> keywords: *SSL does not work, SSL does not encrypt, *SSL is not safe,
> TLS does not work, TLS is not safe, TLS does not encrypt, message
> security not 100% not complete not guaranteed with SSL or TLS, people
> can read your messages with SSL certificate or TLS certificates.

Further, Microsoft says that S can decrypt the message. Why do they
say that? Is this a case where a "mashup" is involved, where C and/or
Z has given permission to S to decrypt? If so, that solves the
riddle. But if S can routinely decrypt, then it's a mystery.

RL

[unruh]

On 2010-11-03, RayLopez99 <raylopez88@gmail.com> wrote:
> On Nov 2, 12:03?pm, unruh <un...@wormhole.physics.ubc.ca> wrote:
>
>>
>> Your system contacts Z and asks for a public key. It then checks the
>> signing authority of that public key against the set of signing
>> authorities it has in its list. If it checks out, it then uses Z's
>> public key to encrypt a random symmentric key, and encrypts the message with
>> that symmetric key, and sends the encrypted symmetric key and the
>> encrypted message out.
>> Thus any S would need to know Z's private key, ?
>>
>> Now, if S could act as ?a man in the middle, and persuade ?your machine
>> that S's public key is really Z's public key, then of course S could
>> read your transmission. That is prevented by the "web of trust" -- the
>> fact that you trust the signing authority who stated that Z's key really
>> was Z's key. Of course if you do not have the signing authority's public
>> key in your system or S has persuaded you (or your distro) to put a bogus public key for
>> that signing authority into your system, the game is up.>O
>>
>> So no, without a lot of work, intermediate machines cannot read your SSL
>> stuff sent to Z, or you ignored the warning from your browser that it
>> did not know the signing authority for the key you are using.
>>
>
> Unruh--you are probably late to this thread. The issue here is not
> spoofing so much as the statement by others in this thread that S (the
> intermediary) *CAN* read your SSL stuff. How it does this is the
> question.

The statements are wrong.

>
> One proposal (and I have yet to see this explicitly): for SSL
> encrypted message routing to work, when involving intermediaries like
> SOAP servers (like S in our A to S to Z transmission of a SSL
> message), S the intermediary *must* be able to decrypt the message.

Nonesense. It just passes it on.

> It contacts the relevant endpoint, Z, gets permission to decrypt, and
> does decrypt. Then it routes the message using the headers

That would be a HUGE HUGE hole in SSL protocol. It might as well not
exist if that were true.

> (unencrypted). Before it transmits the message, S will of course

The headers are ALWAYS unencrypted. That is how the message gets from A
to B.

> encrypt it again, so while the message is in transit nobody can read
> it. But S itself can (and must) read the message for the transmission
> to work.

Bunnybeads.

>
> Can anybody confirm this? I've not seen this on the net, but it's a
> logical inference from what I have seen.
>
> RL

[RayLopez99]

On Oct 29, 8:36*pm, "FromTheRafters" <erra...@nomail.afraid.org>
wrote:

> ***
> Yep, I learned that you are a stupid troll.
>
> Bye-bye
> ***

Here's
a reference for you to 'bone up' on, bonehead: (http://
msdn.microsoft.com/en-us/library/ms733137%28VS.90%29.aspx “End-to-end
security. A secure transport, such as Secure Sockets Layer (SSL)
works
only when the communication is point-to-point. If the message is
routed to one or more SOAP intermediaries before reaching the
ultimate
receiver, the message itself is not protected once an intermediary
reads it from the wire. "

EXPLAIN WHY MESSAGE IS NOT PROTECTED ONCE AN INTERMEDIARY SOAP IS
PRESENT, DOPE.

Ball is in your court. Cowardice and evasion noted.

RL

[unruh]

On 2010-11-07, RayLopez99 <raylopez88@gmail.com> wrote:
> On Oct 29, 8:36?pm, "FromTheRafters" <erra...@nomail.afraid.org>
> wrote:
>
>> ***
>> Yep, I learned that you are a stupid troll.
>>
>> Bye-bye
>> ***
>
> Here's
> a reference for you to 'bone up' on, bonehead: (http://
> msdn.microsoft.com/en-us/library/ms733137%28VS.90%29.aspx ?End-to-end
> security. A secure transport, such as Secure Sockets Layer (SSL)
> works
> only when the communication is point-to-point. If the message is
> routed to one or more SOAP intermediaries before reaching the
> ultimate
> receiver, the message itself is not protected once an intermediary
> reads it from the wire. "
>
> EXPLAIN WHY MESSAGE IS NOT PROTECTED ONCE AN INTERMEDIARY SOAP IS
> PRESENT, DOPE.
>
> Ball is in your court. Cowardice and evasion noted.

YOu are making the assumption that all people at microsoft.com know what
they are talking about. That assumption need not be a good one. That is
another possibility you seem to be avoiding.
Also, a SOAP is a machine which is supposed to make changes to a
document. In order to do so, it MUST be able toread and change the
document. Thus if you are using ssl, the link must be from the original
machine to the intermediary which must be able to decrypt the message.
THe original must therefor sent the message to the SAOP intermiary
encrypted with the intermediary's public key protocol.

That is how I read it.


>
> RL

[FromTheRafters]

"unruh" <unruh@wormhole.physics.ubc.ca> wrote in message
news:slrnidducl.8ik.unruh@wormhole.physics.ubc.ca...
> On 2010-11-07, RayLopez99 <raylopez88@gmail.com> wrote:
>> On Oct 29, 8:36?pm, "FromTheRafters" <erra...@nomail.afraid.org>
>> wrote:
>>
>>> ***
>>> Yep, I learned that you are a stupid troll.
>>>
>>> Bye-bye
>>> ***
>>
>> Here's
>> a reference for you to 'bone up' on, bonehead: (http://
>> msdn.microsoft.com/en-us/library/ms733137%28VS.90%29.aspx ?End-to-end
>> security. A secure transport, such as Secure Sockets Layer (SSL)
>> works
>> only when the communication is point-to-point. If the message is
>> routed to one or more SOAP intermediaries before reaching the
>> ultimate
>> receiver, the message itself is not protected once an intermediary
>> reads it from the wire. "
>>
>> EXPLAIN WHY MESSAGE IS NOT PROTECTED ONCE AN INTERMEDIARY SOAP IS
>> PRESENT, DOPE.
>>
>> Ball is in your court. Cowardice and evasion noted.
>
> YOu are making the assumption that all people at microsoft.com know
> what
> they are talking about. That assumption need not be a good one. That
> is
> another possibility you seem to be avoiding.
> Also, a SOAP is a machine which is supposed to make changes to a
> document. In order to do so, it MUST be able toread and change the
> document. Thus if you are using ssl, the link must be from the
> original
> machine to the intermediary which must be able to decrypt the message.
> THe original must therefor sent the message to the SAOP intermiary
> encrypted with the intermediary's public key protocol.
>
> That is how I read it.

Yes, Transport Layer Security is like the two cans and a string in a
point-to-point communications link. You want to protect from anyone
tapping the string getting your data while still having the users
understand one another. It is about the *string* not about the cans
(diaphrams) or the ears. In this analogy, the TLS would sit between the
diaphrams and the strings and be transparent to the users. It is not
about what the users can and cannot do, it is about what someone tapping
the string would be able to do (nothing, because it is still encrypted
at that point).

If you want to keep your data secure from the people that you have
trusted with the session keys, you should encrypt the data itself before
sending it to the TLS.

I won't be responding to any further posts by this troll until he learns
not to crosspost. :o)

Though I am pleasantly surprised he included the security group this
time, he usually tries to pick groups where he has a chance to look
superior on a given subject even though he obviously lacks clue.

[RayLopez99]

On Nov 7, 9:10*pm, unruh <un...@wormhole.physics.ubc.ca> wrote:

>
> YOu are making the assumption that all people at microsoft.com know what
> they are talking about. That assumption need not be a good one. That is
> another possibility you seem to be avoiding.

Good point. The passage is unclear--it implies that the SOAP
intermediary is an 'exception' to https being secure, akin to a Cross-
site scripting (XSS) attack. But in fact, if your interpretation is
correct, it's not really an exception.

> Also, a SOAP is a machine which is supposed to make changes to a
> document. In order to do so, it MUST be able toread and change the
> document. Thus if you are using ssl, the link must be from the original
> machine to the intermediary which must be able to decrypt the message.
> THe original must therefor sent the message to the SAOP intermiary
> encrypted with the intermediary's public key protocol.
>
> That is how I read it.

Very logical, and it works to explain the passage, except for the fact
it makes the passage trivial. If all Microsoft is saying (and not
just Microsoft--I've seen similar language in a book on WCF by
Resnick, an authority on WCF) is that 'when you send an SSL / TLS
secured message to a SOAP intermediary, since SSL / TLS is only good
for transport and not for the endpoints, don't forget that you must
decrypt the message at the SOAP intermediary', well, this is very
true, but trivial. How is that an exception to https being secure?
An exception like XSS attacks? I think there might be more going on
that nobody in this thread is aware of, but for the time being I guess
we have to settle for your answer.

Thanks for the reply.

RL

[RayLopez99]

On Nov 8, 12:56*am, "FromTheRafters" <erra...@nomail.afraid.org>
wrote:
>
> Yes, Transport Layer Security is like the two cans and a string in a
> point-to-point communications link. You want to protect from anyone
> tapping the string getting your data while still having the users
> understand one another. It is about the *string* not about the cans
> (diaphrams) or the ears. In this analogy, the TLS would sit between the
> diaphrams and the strings and be transparent to the users. It is not
> about what the users can and cannot do, it is about what someone tapping
> the string would be able to do (nothing, because it is still encrypted
> at that point).
>
> If you want to keep your data secure from the people that you have
> trusted with the session keys, you should encrypt the data itself before
> sending it to the TLS.

That last part makes no sense, kind of like you in real life.

If you trust somebody with session keys, why would you want to keep
your data secure from them? Again, see my reply just now to unruh.

Either the passage is trivial (unruh's interpretation, and for now I
have to agree with him), or, there's more going on that none of us is
aware of. That's also a possibility, as I've seen this language in a
textbook. Unless the textbook author was merely parroting the unclear
language from Microsoft, which I guess is possible too.

RL

[Ari Silverstein]

On Sun, 7 Nov 2010 15:44:43 -0800 (PST), RayLopez99 wrote:

> Either the passage is trivial (unruh's interpretation, and for now I
> have to agree with him), or, there's more going on that none of us is
> aware of.

Yeah, you're unaware, that's for ****ing sure. lol
--
Talk about F-Cars - www.ferrarichat.com/forum/member.php?u=89702

[FromTheRafters]

"unruh" <unruh@wormhole.physics.ubc.ca> wrote in message
news:slrnidducl.8ik.unruh@wormhole.physics.ubc.ca...
> On 2010-11-07, RayLopez99 <raylopez88@gmail.com> wrote:
>> On Oct 29, 8:36?pm, "FromTheRafters" <erra...@nomail.afraid.org>
>> wrote:
>>
>>> ***
>>> Yep, I learned that you are a stupid troll.
>>>
>>> Bye-bye
>>> ***
>>
>> Here's
>> a reference for you to 'bone up' on, bonehead: (http://
>> msdn.microsoft.com/en-us/library/ms733137%28VS.90%29.aspx ?End-to-end
>> security. A secure transport, such as Secure Sockets Layer (SSL)
>> works
>> only when the communication is point-to-point. If the message is
>> routed to one or more SOAP intermediaries before reaching the
>> ultimate
>> receiver, the message itself is not protected once an intermediary
>> reads it from the wire. "
>>
>> EXPLAIN WHY MESSAGE IS NOT PROTECTED ONCE AN INTERMEDIARY SOAP IS
>> PRESENT, DOPE.
>>
>> Ball is in your court. Cowardice and evasion noted.
>
> YOu are making the assumption that all people at microsoft.com know what
> they are talking about. That assumption need not be a good one. That is
> another possibility you seem to be avoiding.

They seemed to me to be trying to make the point that it is the *session*
that is encrypted and how that subtle difference is manifested when someone
tries to implement *it* instead of using file encryption (end-to-end as
opposed to point-to-point).

[Registered User]

On Sun, 7 Nov 2010 15:44:43 -0800 (PST), RayLopez99
<raylopez88@gmail.com> wrote:

>On Nov 8, 12:56*am, "FromTheRafters" <erra...@nomail.afraid.org>
>wrote:
>>
>> Yes, Transport Layer Security is like the two cans and a string in a
>> point-to-point communications link. You want to protect from anyone
>> tapping the string getting your data while still having the users
>> understand one another. It is about the *string* not about the cans
>> (diaphrams) or the ears. In this analogy, the TLS would sit between the
>> diaphrams and the strings and be transparent to the users. It is not
>> about what the users can and cannot do, it is about what someone tapping
>> the string would be able to do (nothing, because it is still encrypted
>> at that point).
>>
>> If you want to keep your data secure from the people that you have
>> trusted with the session keys, you should encrypt the data itself before
>> sending it to the TLS.
>
>That last part makes no sense, kind of like you in real life.
>
It makes absolute sense! Intermediate tiers need to decrypt the
envelope. If the letter does not have additional encryption its
contents will be decrypted when the envelope is encrypted.

If the letter is encrypted before it goes in the envelope, the letter
will remain encrypted when an intermediate tier decrypts the envelope.

>If you trust somebody with session keys, why would you want to keep
>your data secure from them? Again, see my reply just now to unruh.
>
You are confusing authentication and authorization. Reading about
roles and memberships may provide some insights.

>Either the passage is trivial (unruh's interpretation, and for now I
>have to agree with him), or, there's more going on that none of us is
>aware of. That's also a possibility, as I've seen this language in a
>textbook. Unless the textbook author was merely parroting the unclear
>language from Microsoft, which I guess is possible too.
>

The problem is something doesn't work the way you expect. This has
occurred before.

regards
A.G.