Need opinion on implementation
JPractitioner
I have the following scenario.
I am connecting to a processor to process ATM transactions. Clearly, I
will be the client, the processor will be the server.
On top of this, we'll need to encrypt PIN and generate PIN block using
session key. (this is where the issue begins)
The session key will will be provided by them. They will do this by
initiating a 0800 message. They will send the 0800 message to us. They
will send this key from time to time.
They will send the key to our ISO client's IP through the client's
OUTGOING port.
for example:
client (192.168.0.188, port 1) and server (192.168.0.189, port 2). the
server will send the 0800 to client's port 1.
The issue here is,
1. the client was never configured with any outgoing port.
2. the client can not serve the 0800 request.
To solve this, I can think of the following implementation
issue 1: configure an outgoing port on the ISO client. i.e. port 1
issue 2: run an ISO server and that ISO server will listen to that
port 1. The ISO server will serve the 0800 message. It will take the
session key, load the key to HSM and reply with 0810.
Moving on,
I need your opinion, can I solve this using the implementation above?
or perhaps, there are better ways?
I'd also like to ask, how do I configure the clien'ts outgoing port?
any code snippets would be great.
Thanks!!
Mark Salter
> The session key will will be provided by them. They will do this by
> initiating a 0800 message. They will send the 0800 message to us. They
> will send this key from time to time.
I guess this session key will itself be encrypted under another key
shared between you and the server? Unless your network is encrypted and
secure, you might want to check?
You are to use this session key to produce PIN blocks?
>
> They will send the key to our ISO client's IP through the client's
> OUTGOING port.
>
> for example:
>
> client (192.168.0.188, port 1) and server (192.168.0.189, port 2). the
> server will send the 0800 to client's port 1.
How many connections do you have?
I think you have one connection...
The server will listen on 192.168.0.189:2, as a 'client' you will
connect to this port and your operating system will very likely assign
your end of this a randomly picked port number, unless you are
*reserving* and specifying a client port (see below for search help).
>
> The issue here is,
>
> 1. the client was never configured with any outgoing port.
If you have a single network connection, traffic can flow in both
directions over it.
The server will have a connection through which it will periodically
send 0800 request (indicating a session key change) and you will receive
the 0800 and respond (0810) perhaps after you have retrieved the session
key, confirmed it is valid and started using it.
Is there a 'commit' stage when both sides start to use the session key,
how do you avoid problems on the change over with transaction 'in
flight'? Perhaps a session key 'start time' is agreed 8) ?
> 2. the client can not serve the 0800 request.
Your client responds, to the server driving session key changes? In
some systems you might be able to initiate a session key change, but it
will depend on the server.
>
> To solve this, I can think of the following implementation
> issue 1: configure an outgoing port on the ISO client. i.e. port 1
>
> issue 2: run an ISO server and that ISO server will listen to that
> port 1. The ISO server will serve the 0800 message. It will take the
> session key, load the key to HSM and reply with 0810.
I think you are missing the fundamentals of network connectivity and are
confusing your self over ports - in most instances it doesn't matter.
Do you have a firewall set-up that limits and needs you to control the
ports used at both ends?
>
> I'd also like to ask, how do I configure the clien'ts outgoing port?
> any code snippets would be great.
I don't think you need to, but I can't be sure without answers to my
questions above.
I searched this mailing list for the words:- fix client port
The top hit :-
holds the answer and also discussion on uber cautious firewall admins -
is there any other type?
--
Mark
DC
we're using vpn connection,
>>I guess this session key will itself be encrypted under another key
>>shared between you and the server? Unless your network is encrypted and
We'll decrypt the session key using the shared key and use that
decrypted session key to encryt the PIN. Anything wrong?
>>I think you have one connection...
>>Is there a 'commit' stage when both sides start to use the session key,
>>how do you avoid problems on the change over with transaction 'in
>>flight'? Perhaps a session key 'start time' is agreed 8) ?
their session key? This is a good question.
Never thought of it. Hmm,... let's see, the transaction will get
rejected because the PIN wouldnt match, no charges occur, the account
holder would just have to transaction one more time. Or perhaps if we
can agree on session key exchange time as you mentioned, and on that
particular second, we could pause the transactions... i.e. Thread.sleep
(5000).
>>Your client responds, to the server driving session key changes? In
>>some systems you might be able to initiate a session key change, but it will depend on the server.
server has to be running on the same port as the clien't outgoing
port.
>>I think you are missing the fundamentals of network connectivity and are
>>confusing your self over ports - in most instances it doesn't matter.
listen while another application to use it as out port. Hmm i sure
don't know a lot about networking
>>Do you have a firewall set-up that limits and needs you to control the
>>ports used at both ends?
client and listening port for my server) freely. I can most definitely
do this right?
Thanks again!
Mark Salter
> Hi Mark, thanks for replying
>
> we're using vpn connection,
>
>>> I guess this session key will itself be encrypted under another key
>>> shared between you and the server? Unless your network is encrypted and
>>> secure, you might want to check? <----- yes you are correct, we do have the shared key
>
> We'll decrypt the session key using the shared key and use that
> decrypted session key to encryt the PIN. Anything wrong?
>
'clear use' would be in a secure place - an HSM.
>>> I think you have one connection...
> Yup.
Ok.
>
>>> Is there a 'commit' stage when both sides start to use the session key,
>>> how do you avoid problems on the change over with transaction 'in
>>> flight'? Perhaps a session key 'start time' is agreed 8) ?
> You mean, before my 0200 reach the server, the server already change
> their session key? This is a good question.
> Never thought of it. Hmm,... let's see, the transaction will get
> rejected because the PIN wouldnt match, no charges occur, the account
> holder would just have to transaction one more time. Or perhaps if we
> can agree on session key exchange time as you mentioned, and on that
> particular second, we could pause the transactions... i.e. Thread.sleep
> (5000).
Perhaps the host could check the PIN with the old key and then the new -
for a 'while' at least.
Even with a wait, synchronisation is hard if not impossible.
>
>>> Your client responds, to the server driving session key changes? In
>>> some systems you might be able to initiate a session key change, but it will depend on the server.
> No, it can't. Thats why I thought, to give the same effect, an ISO
> server has to be running on the same port as the clien't outgoing
> port.
>
>
>>> I think you are missing the fundamentals of network connectivity and are
>>> confusing your self over ports - in most instances it doesn't matter.
> Hmm.. well I never thought of having 1 port for 1 application to
> listen while another application to use it as out port. Hmm i sure
> don't know a lot about networking
>
I think one connection is plenty and I will hope you are worrying about
nothing; I don't see what problem you are thinking of addressing.
>>> Do you have a firewall set-up that limits and needs you to control the
>>> ports used at both ends?
> Yup. But assuming I can use that port i need (as outgoing port for
> client and listening port for my server) freely. I can most definitely
> do this right?
Yes, control of the source port on a client connection is perhaps not
always done. When control is needed it is possible.
You just need to arrange that the source port is reserved - on some
systems this might be harder than on others.
--
Mark
DC
i ve looked into the discussion (http://tinyurl.com/d4ukgb), using
setLocalAddress.
but my ISOClient is still picking its outgoing port randomly..
Here's a snippet of my code
.
.
this.channel = new ASCIIChannel(this.serverIP, this.serverPort, new
GenericPackager(this.genericPackageFileDir));
this.channel.setLocalAddress("192.168.18.6", 1);
this.channel.setTimeout(this.timeOut);
.
.
(note my ISOServer address is 127.0.0.1 and listening to port 5)
so i expect at my server log
<log realm="ISOListener -server-.channel/192.168.18.6:1" at="Mon Apr
20 13:17:00 SGT 2009.968">
but instead i got
log realm="ISOListener -server-.channel/127.0.0.1:4039" at="Mon Apr 20
13:17:00 SGT 2009.968">
Any idea?
Thanks,
DC.
DC
I've looked into org.jpos.iso.BaseChannel.java
I saw the following function
protected Socket newSocket() throws IOException {
try {
if (socketFactory != null)
return socketFactory.createSocket (host, port);
else {
if (timeout > 0) {
Socket s = new Socket();
s.connect (
new InetSocketAddress (host, port),
timeout
);
return s;
} else if (localIface == null && localPort == 0){
return new Socket(host,port);
} else {
InetAddress addr = (localIface == null) ?
InetAddress.getLocalHost() :
InetAddress.getByName(localIface);
return new Socket(host, port, addr, localPort);
}
}
} catch (ISOException e) {
throw new IOException (e.getMessage());
}
}
From that function, it will not allow setLocalAddress if I have my
timeout value. So i tried remove the timeout
.
.
this.channel = new ASCIIChannel(this.serverIP, this.serverPort, new
GenericPackager(this.genericPackageFileDir));
this.channel.setLocalAddress("192.168.18.6", 1);
.
.
.
and that works for the purpose of specifying my ISOClient's outgoing
port.
However, I do need the timeOut value. Any idea on how i can use
specific outgoing port without having to comment out the timeout part?
By the way, why was it coded that way? Any reason why we should not
have both things together?
Thanks,
DC.
Mark Salter
> I've looked into org.jpos.iso.BaseChannel.java
Which revision please?
The latest references connectTimeout (instead of timeout). This change
was made in r2567 towards the end of last year...
You need to update?
>
> and that works for the purpose of specifying my ISOClient's outgoing
> port.
Ok.
>
> However, I do need the timeOut value. Any idea on how i can use
> specific outgoing port without having to comment out the timeout part?
I think you could set the timeout later (after connection is active),
but get the latest code first, I think you will be ok without dropping
your required timeout.
--
Mark
DC
1.6.0
> You need to update?
Yup, I am getting jPOS 1.6.4
> I think you could set the timeout later (after connection is active),
Yeah, i think so, will try later.
By the way, i noticed my programmer's guide is for jPOS 1.4.8. Is
there updates for the programmer's guide too?
Thanks,
DC.
P/s: do u know why on version 1.6.0, timeout cannot be > 0 in order to
set local address?
Alejandro Revilla
> By the way, i noticed my programmer's guide is for jPOS 1.4.8. Is
> there updates for the programmer's guide too?
>
Contact sup...@jpos.org and provide your original purchase e-mail
address and we'll send you a new copy (the latest version is tagged
as r2966).
>
> P/s: do u know why on version 1.6.0, timeout cannot be > 0 in order to
> set local address?
>
I did not look at it but I think there was a bug in the way we were
handling the configuration.
DC
guys, it seems my concern regarding having the same port for 1
ISOServer to listen and for 1 ISOClient to use as outgoing port (using
setLocalAddress) is valid. Today i got this exception (which i
anticpated if my concern is valid)
java.net.BindException: Address already in use: JVM_Bind
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:331)
at java.net.Socket.bind(Socket.java:498)
at java.net.Socket.<init>(Socket.java:307)
at java.net.Socket.<init>(Socket.java:184)
at org.jpos.iso.BaseChannel.newSocket(BaseChannel.java:286)
at org.jpos.iso.BaseChannel.connect(BaseChannel.java:337)
at src.GenericClient.initTxn(GenericClient.java:50)
at src.GenericClient.hit(GenericClient.java:117)
at src.GenericClient.main(GenericClient.java:237)
java.lang.NullPointerException
at src.GenericClient.hit(GenericClient.java:193)
at src.GenericClient.main(GenericClient.java:237)
Now i' m back to square one....
On 20 Apr, 19:58, Alejandro Revilla <a...@jpos.org> wrote:
> > By the way, i noticed my programmer's guide is for jPOS 1.4.8. Is
> > there updates for the programmer's guide too?
>
> There's a more recent version of the guide that covers jPOS 1.6.x
chhil
Mark Salter
> I see, thanks Mark, Alejandro.
>
> guys, it seems my concern regarding having the same port for 1
> ISOServer to listen and for 1 ISOClient to use as outgoing port (using
> setLocalAddress) is valid. Today i got this exception (which i
> anticpated if my concern is valid)
>
> java.net.BindException: Address already in use: JVM_Bind
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:331)
> at java.net.Socket.bind(Socket.java:498)
> at java.net.Socket.<init>(Socket.java:307)
> at java.net.Socket.<init>(Socket.java:184)
> at org.jpos.iso.BaseChannel.newSocket(BaseChannel.java:286)
> at org.jpos.iso.BaseChannel.connect(BaseChannel.java:337)
> at src.GenericClient.initTxn(GenericClient.java:50)
> at src.GenericClient.hit(GenericClient.java:117)
> at src.GenericClient.main(GenericClient.java:237)
> java.lang.NullPointerException
> at src.GenericClient.hit(GenericClient.java:193)
> at src.GenericClient.main(GenericClient.java:237)
>
> Now i' m back to square one....
ports carefully. In the event you *need* to select your own local port
on a client connection, you have to make sure it is never going to be
already in use by your system.
You need to reserve it from the random selection process of your
operating system. How you do so will depend on your operating system.
You also picked two rather low numbers, you may need to start above
1024, but then it depends on your operating system.
If you have a firewall admin that needs you to control each port, then
he will be able to advise which ports you should be using and hopefully
point you to someone who can set your device up not to use the port you
need to?
I am assuming that you did not have two instances of your code running
at the same time? This will not work of course. Which ports did you
try and use? Did you have a single instance of your client running?
--
Mark
Victor Salaman
/V
DC
>> listen while another application to use it as out port.
>nothing; I don't see what problem you are thinking of addressing.
but i have to be able to allow the port being shared by the ISOclient
to write on it and at the same time, to be shared by the ISOserver to
listen on. in other words, they expect me to be a server and a client
that listen and writes to the same port.
i can't specify a port for them to send the 0800. they will send the
0800 to my ISOClient's outgoing port. Hence the issue started...
From your experience/opinion, how do you think I should proceed?
Mark Salter
>>> Hmm.. well I never thought of having 1 port for 1 application to
>>> listen while another application to use it as out port.
>
>> I think one connection is plenty and I will hope you are worrying about
>> nothing; I don't see what problem you are thinking of addressing.
>
> i can use port > 1024 and i can reserve the port from any other usage.
> but i have to be able to allow the port being shared by the ISOclient
> to write on it and at the same time, to be shared by the ISOserver to
> listen on. in other words, they expect me to be a server and a client
> that listen and writes to the same port.
> i can't specify a port for them to send the 0800. they will send the
> 0800 to my ISOClient's outgoing port. Hence the issue started...
I raised this with you at the start...
I think you need *one* connection to your target system. Over this one
link you will send and receive message and they can send 0800 and you
can respond with 0810.
I actually said in my first response:-
"
If you have a single network connection, traffic can flow in both
directions over it.
The server will have a connection through which it will periodically
send 0800 request (indicating a session key change) and you will receive
the 0800 and respond (0810) perhaps after you have retrieved the session
key, confirmed it is valid and started using it.
"
So you connect to the server, perhaps not caring what your local port
is. You can send requests in and get responses and you will
occasionally get 0800's which you will respond to.
You need to be certain of what you are being asked to do. I think you
are confusing yourself completely.
>
>>From your experience/opinion, how do you think I should proceed?
As above.
--
Mark
DC
> link you will send and receive message and they can send 0800 and you
> can respond with 0810.
Perhaps, i'm using the wrong approach.
How would you do it yourself, if I may asked?
(Clearly, I don't know how to create 1 connection that i can use to do
the thing)
Thanks,
DC.
DC
Thanks,
DC
> Another issue would be SO_REUSEADDR and TIME_WAIT on the socket :( ... it's
> really a bad idea to force the local address, and you've evidently seen the
> results of trying to do so.
>
> /V
>
DC
To listen to port x (as server) and to initiate request also from port
x (as client).
Thanks,
DC
On 21 Apr, 15:39, chhil <chil...@gmail.com> wrote:
> Sorry to jump in...
> The only time it wont bind is when the port is already in use...so are you
> are listening on port 1 and and trying to connect connect to port 1 using
> local port as 1?
>
Mark Salter
> Err... what i need to do is,
>
> To listen to port x (as server) and to initiate request also from port
> x (as client).
x can be the same value but not on a single network address.
If you connect using a localport of 16384 to a server socket running on
a *remote* machine listening on port 16384 all will be well.
As previously stated this connection is two-way.
Perhaps that is your confusion - as it can't work 'locally' as you are
testing?
--
Mark
Mark Salter
> How would you do it yourself, if I may asked?
>
> (Clearly, I don't know how to create 1 connection that i can use to do
> the thing)
Perhaps repeat what you have been told you need to achieve by this
system owner?
I still think you are worrying about nothing and confusing yourself with
your test setup - which can't work on one machine as the ports clash.
--
Mark
Alejandro Revilla
> Perhaps repeat what you have been told you need to achieve by this
> system owner?
>
through an X.25 pad or something or it's just the security officer
inventing some sort of security?
DC
need about the setup. I thought i'd just post my answer after getting
the confirmation. But this is taking so long.. so i'll just answer
your question first,,
> Exactly. Why do you need to enforce the client port? are you going
> through an X.25 pad or something or it's just the security officer
> inventing some sort of security?
was:
I will send 0200 to them, they will send 0800 to me (ocassionally).
the 0800 is for key exchange.
they will send the 0800 to the port where i use as outgoing port for
my 0200...
I know for sure now that, this is not feasible.. but still have not
yet get the confirmation about it from them..
will update this thread once i got the updates from them...
Thanks,
DC.
Alejandro Revilla
> is not because of security concern, its because the flow spec i had
> was:
> I will send 0200 to them, they will send 0800 to me (ocassionally).
> the 0800 is for key exchange.
> they will send the 0800 to the port where i use as outgoing port for
> my 0200...
>
exact wording they gave you? I think you are worrying about a problem
that you actually don't have.
I think you don't have to care about the client port and when your
provider says "they will send the 0800 to the port where I use as
outgoing port" they are actually trying to say that they are going to
send the 0800 over the same established socket.
Mark Salter
> Hi, sorry for late reply, i am still yet to get the confirmation i
> need about the setup. I thought i'd just post my answer after getting
> the confirmation. But this is taking so long.. so i'll just answer
> your question first,,
>
>> Exactly. Why do you need to enforce the client port? are you going
>> through an X.25 pad or something or it's just the security officer
>> inventing some sort of security?
>
> is not because of security concern, its because the flow spec i had
> was:
> I will send 0200 to them, they will send 0800 to me (ocassionally).
> the 0800 is for key exchange.
> they will send the 0800 to the port where i use as outgoing port for
> my 0200...
I think this probably means the exchanges will take place over a single
connection, not separate ones.
This would have no implication on ports. You would just need to deal
with messages arriving that were not responses! No real problem.
>
> I know for sure now that, this is not feasible.. but still have not
> yet get the confirmation about it from them..
They might want two separate connections one into your system they
connect to and one on their system for you to connect to, but I doubt that.
>
> will update this thread once i got the updates from them...
Ok.
--
Mark
Mark Salter
> I think you don't have to care about the client port and when your
> provider says "they will send the 0800 to the port where I use as
> outgoing port" they are actually trying to say that they are going to
> send the 0800 over the same established socket.
+ lots
8)
--
Mark