RTT wrote:
Man in the Middle attacks don't work if the man in the middle
don't know how to handle the encrypted data/protocol he is
intercepting.
True, and how do you manage that is not happening?
Can't be happening because the man in the middle can't generate valid
data, or alter
It is a very simple monitoring system.
SSL is okay for this as far as I am concerned.
As others have say to you already, just concentrate your efforts in the
development of the client and server code. Leave the data encryption to
the last stage of the project.
Starting with the SSL
With a stolen key that's easy.
Sure, and this is exactly what SSL try to circumvent.
But not so easy if the encrypt key is not a fixed value, but a variable
one. The attacker will need to stole the client or server code and
reverse engineering it too.
This is also valid for SSL.
No,
So, leave SSL apart for now.
I don't see any reasons to leave the SSL because I already spent 3 weeks
with making lot of tests and have learned much about SSL and I will
continue.
I am also hoping that you guys try to understand my approach instead of
asking to leave it.
SSL is good enough
SOLVED!!
-Original Message-
From: daniel cc
Sent: Thursday, January 27, 2011 7:33 PM
To: ICS support mailing
Subject: Re: [twsocket] TWSocketServer and TWSocket Port
So, leave SSL apart for now.
I don't see any reasons to leave the SSL because I already spent 3 weeks
with making
RTT wrote:
With a stolen key that's easy.
Sure, and this is exactly what SSL try to circumvent.
But not so easy if the encrypt key is not a fixed value, but a
variable one. The attacker will need to stole the client or server
code and reverse engineering it too.
This is also valid for
On 27-01-2011 18:27, Arno Garrels wrote:
Without the certificate(s) and private key(s) he may intercept transparently
as long as he likes. When he wants to decrypt the session on the fly he
has to go thru the handshake process on behave of the victim by presenting
the stolen certificate(s),
RTT wrote:
That's why the security agencies don't like closed protocols.
Nobody knows whether a proprietary security protocol has some
built-in universal key, given i.e. to a security agency.
That's also why users should not rely on proprietary security
protocols and cryptographic algorithms.
Hello all,
If I have server and client component at one side,
server and client component at the other side
Side A: TWSocketServer and TWSocket == Acts as client
Side B: TWSocketServer and TWSocket == Acts as server
Side A connects automatically to the site B because site A is acting as client
I would like to use the same port which the site A uses when it connects
to the site B.
Yes, you can have a same listening port at both sides.
--
francois.pie...@overbyte.be
http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
I would like to use the same port which the site A uses when it connects
to the site B.
Yes, you can have a same listening port at both sides.
Thanks for the response.
Yes,
I know I can listen same ports but my question is,
can I do that at Site A without opening any ports at the
I would like to use the same port which the site A uses when it connects
to the site B.
Yes, you can have a same listening port at both sides.
Thanks for the response.
Yes,
I know I can listen same ports but my question is,
can I do that at Site A without opening any ports at the
The use only one socket and make all communications over that unique
connection. No other choise in your situation.
Thanks Francois,
Please do correct me if I am wrong.
Now,
You are saying that it is not possible to have only server port opened, I
need to open port 443 in both sites.
Site
Please do correct me if I am wrong.
Now,
You are saying that it is not possible to have only server port opened, I
need to open port 443 in both sites.
Site A port 443 need to be open from PC and from the firewall.
Site B port 443 need to be open from PC and from firewall.
No, I didn't meant
(I am using SSL sockets in both sites)
Why you insist in use SSL if the client and server applications are
coded by you?!! Why use a standard that only exist because of the need
to connect many different implementations of clients to many different
implementations of servers?
You will be
RTT wrote:
(I am using SSL sockets in both sites)
Why you insist in use SSL if the client and server applications are
coded by you?!! Why use a standard that only exist because of the need
to connect many different implementations of clients to many different
implementations of servers?
(I am using SSL sockets in both sites)
Why you insist in use SSL if the client and server applications are
coded by you?!! Why use a standard that only exist because of the need
to connect many different implementations of clients to many different
implementations of servers?
You will be much
Thanks Arno,
Your answer is just a music to my ears :)
RTT wrote:
(I am using SSL sockets in both sites)
Why you insist in use SSL if the client and server applications are
coded by you?!! Why use a standard that only exist because of the need
to connect many different implementations of
SSL/TLS aktually uses common, powerful and strong encryption algorithms.
However secure peer to peer communication is much more than just that.
SSL security includes, for instance, peer verification and protects
against Man in the Middle attacks.
Man in the Middle attacks don't work if the
RTT wrote:
SSL/TLS aktually uses common, powerful and strong encryption
algorithms. However secure peer to peer communication is much more
than just that. SSL security includes, for instance, peer
verification and protects against Man in the Middle attacks.
Man in the Middle attacks don't
Man in the Middle attacks don't work if the man in the middle
don't know how to handle the encrypted data/protocol he is
intercepting.
True, and how do you manage that is not happening?
Can't be happening because the man in the middle can't generate valid
data, or alter intercepted data
RTT,
First,
I am not building a bank system where I would need extremely high security.
It is a very simple monitoring system.
SSL is okay for this as far as I am concerned.
You may be right or may not.
For me the mosty important here is to learn one thing at a time.
If I listen you,
I have to
RTT:
Why you insist in use SSL if the client and server applications are
coded by you?!! Why use a standard that only exist because of the need
to connect many different implementations of clients to many different
implementations of servers?
It's easy to implement encryption but you'll have
23 matches
Mail list logo
