Anybody know how https *really* works? I didn't think so
So my book on https and Windows Communication Foundation technology
says that if any computer between your SSL certificate secured
computer and the client machine reading this certificate does not
support SSL, then the entire https link is not secure and your data
can be compromised. That makes no sense to me, because I thought the
entire data stream is encrypted, but that's what it says. And I've
even seen this on the net.
So why do people blindly trust SSL and HTTPS as if it's unbreakable?
Is it because most traffic goes through at most two or three hops, and
likely these hops are up-to-date and support SSL?
Even if so, you're taking a risk that somewhere between somebody will
fail to support SSL and your message will be unencrypted.
Bet most if not all of you reading this thread did not know this. So
called experts, right.
Re: Anybody know how https *really* works? I didn't think so
"RayLopez99" <raylopez88@gmail.com> wrote in message
news:3b8ac230-21fa-4b5f-8758-3ed63416f172@j18g2000yqd.googlegroups.com...
> So my book on https and Windows Communication Foundation technology
> says that if any computer between your SSL certificate secured
> computer and the client machine reading this certificate does not
> support SSL, then the entire https link is not secure and your data
> can be compromised. That makes no sense to me, because I thought the
> entire data stream is encrypted, but that's what it says. And I've
> even seen this on the net.
Encryption is only as secure as the key management system is.
> So why do people blindly trust SSL and HTTPS as if it's unbreakable?
Because they don't understand security as it pertains to encryption (or
vice versa).
> Is it because most traffic goes through at most two or three hops, and
> likely these hops are up-to-date and support SSL?
???
> Even if so, you're taking a risk that somewhere between somebody will
> fail to support SSL and your message will be unencrypted.
It just unencrypts, like that?
....I don't think so.
> Bet most if not all of you reading this thread did not know this. So
> called experts, right.
I don't think that you really fully understand what you are talking
about, so it seems ironic when you lamely attempt to insult and troll
those you somehow believe to be *experts* in so many disparate
crossposted groups.
Re: Anybody know how https *really* works? I didn't think so
On Oct 28, 5:47*pm, RayLopez99 <raylope...@gmail.com> wrote:
> So my book on https and Windows Communication Foundation technology
> says that if any computer between your SSL certificate secured
> computer and the client machine reading this certificate does not
> support SSL, then the entire https link is not secure and your data
> can be compromised. *That makes no sense to me, because I thought the
> entire data stream is encrypted, but that's what it says. *And I've
> even seen this on the net.
>
> So why do people blindly trust SSL and HTTPS as if it's unbreakable?
> Is it because most traffic goes through at most two or three hops, and
> likely these hops are up-to-date and support SSL?
>
> Even if so, you're taking a risk that somewhere between somebody will
> fail to support SSL and your message will be unencrypted.
>
> Bet most if not all of you reading this thread did not know this. *So
> called experts, right.
>
> RL
Your profile suggests that you work in the agricultural industry. If
those who work in the agricultural industry knew that you're giving
them a bad name, I'm sure they wouldn't hesitate to toss you into the
corn feeder a second time.
Re: Anybody know how https *really* works? I didn't think so
On 10/28/2010 10:04 PM, idbeholda wrote:
> On Oct 28, 5:47 pm, RayLopez99<raylope...@gmail.com> wrote:
>> So my book on https and Windows Communication Foundation technology
>> says that if any computer between your SSL certificate secured
>> computer and the client machine reading this certificate does not
>> support SSL, then the entire https link is not secure and your data
>> can be compromised. That makes no sense to me, because I thought the
>> entire data stream is encrypted, but that's what it says. And I've
>> even seen this on the net.
>>
>> So why do people blindly trust SSL and HTTPS as if it's unbreakable?
>> Is it because most traffic goes through at most two or three hops, and
>> likely these hops are up-to-date and support SSL?
>>
>> Even if so, you're taking a risk that somewhere between somebody will
>> fail to support SSL and your message will be unencrypted.
>>
>> Bet most if not all of you reading this thread did not know this. So
>> called experts, right.
>>
>> RL
>
> Your profile suggests that you work in the agricultural industry. If
> those who work in the agricultural industry knew that you're giving
> them a bad name, I'm sure they wouldn't hesitate to toss you into the
> corn feeder a second time.
Around these parts, wood chippers are real popular.
Re: Anybody know how https *really* works? I didn't think so
On Oct 29, 3:44*am, "FromTheRafters" <erra...@nomail.afraid.org>
wrote:
> "RayLopez99" <raylope...@gmail.com> wrote in message
>
> news:3b8ac230-21fa-4b5f-8758-3ed63416f172@j18g2000yqd.googlegroups.com...
>
> > So my book on https and Windows Communication Foundation technology
> > says that if any computer between your SSL certificate secured
> > computer and the client machine reading this certificate does not
> > support SSL, then the entire https link is not secure and your data
> > can be compromised. *That makes no sense to me, because I thought the
> > entire data stream is encrypted, but that's what it says. *And I've
> > even seen this on the net.
>
> Encryption is only as secure as the key management system is.
Nope, Shiite->4Brains, that' s NOT what we are talking about. Try
again. We are talking about HTTPS, not key management. Yes, it's
true that key management is only as secure as the lock on your door to
the secondary storage holding said keys, but again, that's not at
issue here.
>
> > So why do people blindly trust SSL and HTTPS as if it's unbreakable?
>
> Because they don't understand security as it pertains to encryption (or
> vice versa).
>
> > Is it because most traffic goes through at most two or three hops, and
> > likely these hops are up-to-date and support SSL?
>
> ???
Right. ???. That's your value add to this debate: ???. That should
be your middle name: ??? The Reflex.
>
> > Even if so, you're taking a risk that somewhere between somebody will
> > fail to support SSL and your message will be unencrypted.
>
> It just unencrypts, like that?
Yes, just like that. What you fail to understand (among your many
other failures) is the difference between message level security and
transport level security. HTTPS is the latter not the former. 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. Additionally, the client authentication
information is available only to the first intermediary and must be
transmitted to the ultimate received in out-of-band fashion, if
necessary. This applies even if the entire route uses SSL security
between individual hops. Because message security works directly with
the message and secures the XML in it, the security stays with the
message regardless of how many intermediaries are involved with the
message before it reaches the ultimate receiver. This enables true end-
to-end security scenario.”)
>
> ...I don't think so.
>
You *STILL* don't think so, even after reading the above? Man youz
stupid.
> > Bet most if not all of you reading this thread did not know this. *So
> > called experts, right.
>
> I don't think that you really fully understand what you are talking
> about, so it seems ironic when you lamely attempt to insult and troll
> those you somehow believe to be *experts* in so many disparate
> crossposted groups.
NOT. I hope you lerned something from this thread, dopehead.
Anybody else? C'mon down! Insults are free of charge.
Re: Anybody know how https *really* works? I didn't think so
On Oct 29, 1:32*pm, RayLopez99 <raylope...@gmail.com> wrote:
>
> Yes, just like that. *What you fail to understand (among your many
> other failures) is the difference between message level security and
> transport level security. *HTTPS is the latter not the former. *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. Additionally, the client authentication
> information is available only to the first intermediary and must be
> transmitted to the ultimate received in out-of-band fashion, if
> necessary. This applies even if the entire route uses SSL security
> between individual hops. Because message security works directly with
> the message and secures the XML in it, the security stays with the
> message regardless of how many intermediaries are involved with the
> message before it reaches the ultimate receiver. This enables true end-
> to-end security scenario.”)
>
The only thing left to debate--and I doubt the small minds in this
group has the capacity to address this issue (no thanks in advance)--
is how often "SOAP intermediaries" are present in a 'typical' message
route. I would bet that for most 'routine' messages such as home user
to bank server, there would be no intermediaries, and the ISP server
is just "pass through" and would not require SOAP (I would imagine).
But this is a question for a real expert, not the dunces that hang
around the virtual water cooler that passes for Usenet these days.
Re: Anybody know how https *really* works? I didn't think so
"RayLopez99" <raylopez88@gmail.com> wrote in message
news:a19c2475-597a-4a95-a492-cc9038ceeb09@l17g2000yqe.googlegroups.com...
On Oct 29, 3:44 am, "FromTheRafters" <erra...@nomail.afraid.org>
wrote:
> "RayLopez99" <raylope...@gmail.com> wrote in message
>
> news:3b8ac230-21fa-4b5f-8758-3ed63416f172@j18g2000yqd.googlegroups.com...
>
> > So my book on https and Windows Communication Foundation technology
> > says that if any computer between your SSL certificate secured
> > computer and the client machine reading this certificate does not
> > support SSL, then the entire https link is not secure and your data
> > can be compromised. That makes no sense to me, because I thought the
> > entire data stream is encrypted, but that's what it says. And I've
> > even seen this on the net.
>
> Encryption is only as secure as the key management system is.
Nope, Shiite->4Brains, that' s NOT what we are talking about.
***
So it just magically unencrypts itself?
***
Try again. We are talking about HTTPS, not key management. Yes, it's
true that key management is only as secure as the lock on your door to
the secondary storage holding said keys, but again, that's not at
issue here.
***
So it just magically unencrypts itself?
***
> > So why do people blindly trust SSL and HTTPS as if it's unbreakable?
>
> Because they don't understand security as it pertains to encryption
> (or
> vice versa).
>
> > Is it because most traffic goes through at most two or three hops,
> > and
> > likely these hops are up-to-date and support SSL?
>
> ???
Right. ???. That's your value add to this debate: ???. That should
be your middle name: ??? The Reflex.
***
That was an indication that I didn't understand what you were talking
about, but I see now what that was so.
***
> > Even if so, you're taking a risk that somewhere between somebody
> > will
> > fail to support SSL and your message will be unencrypted.
>
> It just unencrypts, like that?
Yes, just like that. What you fail to understand (among your many
other failures) is the difference between message level security and
transport level security. HTTPS is the latter not the former.
***
Why the animosity? Can you explain how something can encrypt at one end,
and decrypt at the other, without some kind of key being involved?
***
[...]
> ...I don't think so.
You *STILL* don't think so, even after reading the above? Man youz
stupid.
***
Not really, it's just that you not only fail to make sense, you fail to
understand the subject enough to explain to me what you actually meant.
....and you're still acting like an ******* toward me for no good reason
(aside from the obvious trolling that is).
***
> > Bet most if not all of you reading this thread did not know this. So
> > called experts, right.
>
> I don't think that you really fully understand what you are talking
> about, so it seems ironic when you lamely attempt to insult and troll
> those you somehow believe to be *experts* in so many disparate
> crossposted groups.
NOT. I hope you lerned something from this thread, dopehead.
Re: Anybody know how https *really* works? I didn't think so
On Oct 29, 9:36*pm, "FromTheRafters" <erra...@nomail.afraid.org>
wrote:
> ***
> Yep, I learned that you are a stupid troll.
>
> Bye-bye
> ***
Nope. You fail to understand how transport security works. The one
passage that was not flamebait you clipped (and I reproduce it again,
below).
So, where you trolling then? You clearly have no interest in lerning
anything from this thread, trollfeeder.
And I don't know why SOAP intermediaries break https. That really was
my question to the group.
Bye.
RL
(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. Additionally, the client authentication
information is available only to the first intermediary and must be
transmitted to the ultimate received in out-of-band fashion, if
necessary. This applies even if the entire route uses SSL security
between individual hops. Because message security works directly with
the message and secures the XML in it, the security stays with the
message regardless of how many intermediaries are involved with the
message before it reaches the ultimate receiver. This enables true
end-
to-end security scenario.”)
Re: Anybody know how https *really* works? I didn't think so
RayLopez99 wrote:
>
> And I don't know why SOAP intermediaries break https. That really was
> my question to the group.
>
Perhaps Microsoft didn't explain it well enough for you.
Design 1. C (client) -- internet -- Z (destination server)
If your client uses HTTPS and the URL of Z, then your message is safe.
Design 2. C -- internet -- S (intermediary) -- internet -- Z
If your client uses the URL of S, then S uses the URL of Z (even if
they're both using HTTPS) then your message may be read/altered by S.
What was not said is that in design 2, S should really be considered C's
destination, and Z is S's destination - and that protocol encryption
(HTTPS) only protects your message on its path through the internet.
If you don't want S to be able to read/alter your message then encrypt
the message so that only Z can read it - or use design 1 and HTTPS.
Re: Anybody know how https *really* works? I didn't think so
On Thu, 28 Oct 2010 15:47:35 -0700 (PDT), RayLopez99 wrote:
> So my book
What book?
> on https and Windows Communication Foundation technology
> says that if any computer between your SSL certificate secured
> computer and the client machine reading this certificate does not
> support SSL, then the entire https link is not secure and your data
> can be compromised. That makes no sense to me, because I thought the
> entire data stream is encrypted, but that's what it says. And I've
> even seen this on the net.
Where?
> So why do people blindly trust SSL and HTTPS as if it's unbreakable?
> Is it because most traffic goes through at most two or three hops, and
> likely these hops are up-to-date and support SSL?
>
> Even if so, you're taking a risk that somewhere between somebody will
> fail to support SSL and your message will be unencrypted.
>
> Bet most if not all of you reading this thread did not know this. So
> called experts, right.
*roflmao*
--
"The Toast of Buffalo! = http://tinyurl.com/2v9sjf9
Ari himself, with his unerring sense of what is hip, contributed a box
of doughnuts
from Famous Doughnuts, a company he owns."
Re: Anybody know how https *really* works? I didn't think so
On Oct 30, 4:19*am, Jason Keats <jke...@melbpcDeleteThis.org.au>
wrote:
> RayLopez99 wrote:
>
> > And I don't know why SOAP intermediaries break https. *That really was
> > my question to the group.
>
> Perhaps Microsoft didn't explain it well enough for you.
Neither did you Jason, but I appreciate the attempt. Please read on
however.
>
> Design 1. C (client) -- internet -- Z (destination server)
>
> If your client uses HTTPS and the URL of Z, then your message is safe.
>
> Design 2. C -- internet -- S (intermediary) -- internet -- Z
>
> If your client uses the URL of S, then S uses the URL of Z (even if
> they're both using HTTPS) then your message may be read/altered by S.
What are you saying here? Are you saying that S has the ability to
"alter" your message, by say garbling it? To make it unreadable?
(That is, change every letter Y to X and Z character to A, etc? That
would be simple vandalism, and not really a security 'breach' in my
mind. Or are you saying that S has a private key to the HTTPS and can
unencrypt your encrypted message? That was what I thought originally--
and it's still not clear how S can get a private key--only "Z" has
such a key (that's my understanding). I thought HTTPS uses some form
of asymmetric public key (I trust you know what this is), and that the
only holder of the private key is Z. But if HTTPS uses a symmetric
key, then I can see how S can indeed decrypt the message from C and
read it. Please explain. That's the last time I use "please" in
this thread BTW.
>
> What was not said is that in design 2, S should really be considered C's
> destination, and Z is S's destination - and that protocol encryption
> (HTTPS) only protects your message on its path through the internet.
Again, that is how I thought things work: using a asymmetric key,
that's exactly how things should work: every two points in a chain of
transmission is as strong as the next two points--there are no weak
links.
>
> If you don't want S to be able to read/alter your message then encrypt
> the message so that only Z {YES, THIS IS MESSAGE SECURITY, I AGREE} can read it - or use design 1 and HTTPS {I DON'T SEE HOW}
Re: Anybody know how https *really* works? I didn't think so
RayLopez99 wrote:
>>
>> Design 2. C -- internet -- S (intermediary) -- internet -- Z
>>
>> If your client uses the URL of S, then S uses the URL of Z (even if
>> they're both using HTTPS) then your message may be read/altered by S.
>
> What are you saying here? Are you saying that S has the ability to
> "alter" your message, by say garbling it? To make it unreadable?
> (That is, change every letter Y to X and Z character to A, etc? That
> would be simple vandalism, and not really a security 'breach' in my
> mind. Or are you saying that S has a private key to the HTTPS and can
> unencrypt your encrypted message? That was what I thought originally--
> and it's still not clear how S can get a private key--only "Z" has
> such a key (that's my understanding).
As I said, in design 2, C is really communicating with S. If you wrote
S, then all is good - you can probably trust it. However, the service S
receives the original (decrypted) message - because its URL was used by C.
S's job is to communicate with Z. If it uses HTTPS to do that, then the
original message is again (protocol) encrypted and sent on its way to Z.
All anyone is saying is that because C was "talking" to S (using HTTPS),
and not directly to Z, then S gets to see/read the original message
(assuming no message encryption before being posted by C).
Possible reasons for having an intermediary in the process include:
- load balancing (there could really be several Z's)
- S's job may be to translate/transpose the original message into a form
that Z can understand
- extra security: the firewall between C and S may be configured
differently to the one between S and Z
Re: Anybody know how https *really* works? I didn't think so
On Oct 31, 4:06*am, Jason Keats <jke...@melbpcDeleteThis.org.au>
wrote:
> RayLopez99 wrote:
>
> >> Design 2. C -- internet -- S (intermediary) -- internet -- Z
>
> >> If your client uses the URL of S, then S uses the URL of Z (even if
> >> they're both using HTTPS) then your message may be read/altered by S.
>
> > What are you saying here? *Are you saying that S has the ability to
> > "alter" your message, by say garbling it? *To make it unreadable?
> > (That is, change every letter Y to X and Z character to A, etc? *That
> > would be simple vandalism, and not really a security 'breach' in my
> > mind. *Or are you saying that S has a private key to the HTTPS and can
> > unencrypt your encrypted message? *That was what I thought originally--
> > and it's still not clear how S can get a private key--only "Z" has
> > such a key (that's my understanding).
>
> As I said, in design 2, C is really communicating with S. If you wrote
> S, then all is good - you can probably trust it. However, the service S
> receives the original (decrypted) message - because its URL was used by C..
>
> S's job is to communicate with Z. If it uses HTTPS to do that, then the
> original message is again (protocol) encrypted and sent on its way to Z.
>
> All anyone is saying is that because C was "talking" to S (using HTTPS),
> and not directly to Z, then S gets to see/read the original message
> (assuming no message encryption before being posted by C).
>
> Possible reasons for having an intermediary in the process include:
> - load balancing (there could really be several Z's)
> - S's job may be to translate/transpose the original message into a form
> that Z can understand
> - extra security: the firewall between C and S may be configured
> differently to the one between S and Z
Are you sure of this? You use the term "load balancing" which is a
term of art database engineers use, so I take it you have some
knowledge of this area, but frankly your suggestion that what people
are saying about HTTPS and intermediaries is that the intermediary can
decrypt an HTTPS stream and read the unencrypted message is a bit daft
to me.
Here's why: if S, the intermediary, has the ability to decrypt the
SSL certificate, it means it also has a private key (like Z does).
That means at some point Z, the final destination endpoint, gave S the
private key to decrypt message streams--otherwise how could S do it?
Or perhaps C, the client, did. In either case somebody at either
endpoint had to 'trust' S. If that trust was misplaced, and it turns
out S is a crook, well that's life--but somebody made the conscious
decision to trust S.
Does this make sense? So 'human error' in trusting an intermediary
like S is what Microsoft is talking about? That should be made more
clear if so.
Re: Anybody know how https *really* works? I didn't think so
RayLopez99 wrote:
>
> Here's why: if S, the intermediary, has the ability to decrypt the
> SSL certificate, it means it also has a private key (like Z does).
> That means at some point Z, the final destination endpoint, gave S the
> private key to decrypt message streams--otherwise how could S do it?
> Or perhaps C, the client, did.
<snip>
>
> Does this make sense?
Re: Anybody know how https *really* works? I didn't think so
"Jason Keats" <jkeats@melbpcDeleteThis.org.au> wrote in message
news:cKyzo.1104$MF5.193@viwinnwfe02.internal.bigpo nd.com...
> RayLopez99 wrote:
>>
>> Here's why: if S, the intermediary, has the ability to decrypt the
>> SSL certificate, it means it also has a private key (like Z does).
>> That means at some point Z, the final destination endpoint, gave S
>> the
>> private key to decrypt message streams--otherwise how could S do it?
>> Or perhaps C, the client, did.
> <snip>
>>
>> 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.
Re: Anybody know how https *really* works? I didn't think so
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?
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? If routing is the
reason, you can (I would suppose) just keep the headers decrypted and
route the message using the headers, which is conventional.
Please confirm. That's the second time I've used please in this post
and twice too many.
Re: Anybody know how https *really* works? I didn't think so
On Sat, 30 Oct 2010 14:02:58 -0700 (PDT), RayLopez99 wrote:
> Please explain. That's the last time I use "please" in
> this thread BTW.
Outside of being an assclown, you're a liar too. How's that working
for you in this thread? lol
--
Passwords, people, they are not just for game shows. If you refuse to
make the effort to remember a few long, diverse passwords, then don't
scream at me when your FICO is 496 and your bank accounts are zeroed
out.
Re: Anybody know how https *really* works? I didn't think so
"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.
***
Re: Anybody know how https *really* works? I didn't think so
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.
Re: Anybody know how https *really* works? I didn't think so
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?
Re: Anybody know how https *really* works? I didn't think so
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?
Re: Anybody know how https *really* works? I didn't think so
["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.
Re: Anybody know how https *really* works? I didn't think so
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.
Re: Anybody know how https *really* works? I didn't think so
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.
Re: Anybody know how https *really* works? I didn't think so
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.
Re: Anybody know how https *really* works? I didn't think so
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.
Anybody know how https *really* works? I didn't think so 
Linear Mode
