Given a NDA forbids me from giving you more details let me give you
an analogy with postal services: I assume you know of postal services
where you can get a delivery receipt. you can get a receipt that the
recipient was notified, if the postman gets shot along the way, the
postal service will
On Tue, May 19, 2009 at 10:53:05AM +0200, João Távora wrote:
Given a NDA forbids me from giving you more details let me give you
an analogy with postal services: I assume you know of postal services
where you can get a delivery receipt. you can get a receipt that the
recipient was notified,
The equivalent of application acknowledgment would be the
*letter* saying to the person once you read this, return
the attached form. Then you need the application has
read the message and done something about it.
Certainly. But I don't need this. I just need registered mail, that is
be
From: owner-openssl-us...@openssl.org On Behalf Of Ger Hobbelt
Sent: Monday, 18 May, 2009 13:04
Quite a bit has been covered in the answers so far, but
there's still some material left.
Apparently. Much that I agree with, or is redundant, snipped.
Considering the 'guaranteed delivery'
João Távora wrote:
Given a NDA forbids me from giving you more details let me give you
an analogy with postal services: I assume you know of postal services
where you can get a delivery receipt. you can get a receipt that the
recipient was notified, if the postman gets shot along the way,
On Tue May 19 2009, Dave Thompson wrote:
From: owner-openssl-us...@openssl.org On Behalf Of Ger Hobbelt
Sent: Monday, 18 May, 2009 13:04
- - - snip - - -
c) the 'guaranteed delivery' I mentioned before: VMS offers
this as a message-based protocol, but you can easily convert
that
-
What this article says is this: if you *received* data from TCP
connection it will be without duplication or losing data. It doesn't
say: if you *send* data it will be received correctly by other host.
It's impossible to garantee.
--
Andrey Koltsov
With TCP you basically don't know
:59 AM
Subject: Re: SSL attack scenario
JoΓ£o TΓ΅vora ΠΏΠΈΡ�ΠµΡ‚:
What this article says is this: if you *received* data from TCP connection
it will be without duplication or losing data. It doesn't say: if you
*send* data it will be received correctly by other host. It's impossible
* Nikos Balkanas wrote on Mon, May 18, 2009 at 15:29 +0300:
Wikipedia is right in principle, but doesn't cover the case of TCP
hijacking.
I think this is out of scope,
TCP is said to be reliable, not neccesarily secure.
oki,
Steffen
--[ end of message
João wrote:
TCP does not provide delivery assurance. If the application needs
to know
the data got through, it must use application-level
ackwowledgements. SSL
does not change this and provides the same set of guarantees and
assurances
TCP does.
I'm sorry to disagree but TCP,
On Sun, May 17, 2009 at 8:22 PM, João Távora joaotav...@gmail.com wrote:
Maybe I didn't really fully explain myself, the problem is not really
ensuring secrecy and integrity, it's ensuring delivery.
[...]
In this case the attacker would have tampered with the delivery assurance of
TCP but none
On Mon, May 18, 2009 at 6:26 PM, David Schwartz dav...@webmaster.com wrote:
[...]
Whoops. I was writing my response while David's made it already
across. His is shorter and saying exactly the same.
ACKs are not important. There's message, there's stream and the
security breach. The latter does
2009/5/18 Nikos Balkanas nbalka...@gmail.com:
It would require a lot of effort, but a transparent proxy, can rewrite IP
source headers, sequence numbers, ACKs and if it has followed all algos and
key exchanges, even regenerate those. HMAC is nothing more than a glorified
CRC encoded with some
On Mon, May 18, 2009, Kyle Hamilton wrote:
Both of which are described as hard problems. It's not known
whether they qualify as NP-complete, but they definitely qualify as
NP-hard (NP meaning 'nonpolynomial time', or 'the amount of time
required to do it is logarithmic with how much
David,
I think we're drifting a little bit from my original question here. I
certainlly don't mean to imply that there's anything wrong with SSL or
the OpenSSL's implementation, I just want to discover if it does what
I want.
TCP specifically does *not* communicate ACKs up to the
Joao Tavora wrote:
Certainly! I never said it did. TCP ensures delivery to the host,
not the application. But it does ensure it up to the host, or if
that cant be achieved the peer host is appropriately notified.
Right, none of which has any application-level consequences. These are all
Hi,
I've got a newbie question about a possible SSL/OpenSSL
Consider two machines A and B and a man-in-the-middle, Z, who can
snoop traffic.
A and B exchange certificates securely, i.e. Z lets the SSL handshake
through. Therefore A sends a first application-data message to B.
Z cannot
No.
Part of the SSL/TLS handshake protocol is the definition of what the
content of the message should include -- i.e., the HMAC. If it
doesn't exist or is different from what it's supposed to be, the side
that failed to validate it sends a decryption_error fatal alert and
closes the connection.
Hi
I'm glad for your negative answer and that's also what I suspect :-)
... but I didn't really understand why.
Maybe I didn't really fully explain myself, the problem is not really
ensuring secrecy and integrity, it's ensuring delivery.
As I understand it this is normally done with TCP
João wrote:
Hi
I'm glad for your negative answer and that's also what I suspect :-)
... but I didn't really understand why.
Maybe I didn't really fully explain myself, the problem is not really
ensuring secrecy and integrity, it's ensuring delivery.
No protocol can ensure the other side
TCP does not provide delivery assurance. If the application needs
to know
the data got through, it must use application-level
ackwowledgements. SSL
does not change this and provides the same set of guarantees and
assurances
TCP does.
I'm sorry to disagree but TCP, unlike UDP, does
TCP allows for hijacking -- but the fact that the SSL/TLS layer uses
secret, ever-changing HMACs means that an attacker cannot pass any
data to the hijacked session without it being detected and a protocol
error resulting. (Much less the encryption key for all but NULL
ciphers.)
TCP guarantees
João Távora пишет:
TCP does not provide delivery assurance. If the application needs
to know
the data got through, it must use application-level ackwowledgements.
SSL
does not change this and provides the same set of guarantees and
assurances
TCP does.
I'm sorry to disagree but TCP,
23 matches
Mail list logo
