서버랑 통신하는 데탑 클라이언트는 처음 만들어보니

[웹땔감dz(223.33)]

보안을 어떻개 처리해야할지 넘 고민된다

구루님 도와주새여 ㅜㅜ

[아둔☎2.78™(roidz)]

https://www.example-code.com/java/dh_key_exchange.asp

[웹땔감dz(223.33)]

저희 서버에서 받은 데이터를 다른 서버로 전송하는 역할을 하는 중개 클라에언트인데 다른 서버는 저희랑 전혀 관련 없는 서버에여

[아둔☎2.78™(roidz)]

http://stackoverflow.com/questions/22479508/java-diffie-hellman-key-exchange

[웹땔감dz(223.33)]

그래서 수신측이 저희 데이터를 검증하지는 않는데... 데이터가 중간에 변조되지 않는다는 보장을 할 수 있는 방법이 뭐가 있을까요 TLS는 전송단계 수준에서 보안이 인증된다치고

[아둔☎2.78™(roidz)]

흠... 파이프라인이라..

[웹땔감dz(223.33)]

저희 애플리케이션의 전송 부분을 후킹해서 변조한다거나 하는 걸 막을 수가 있나얌?

[아둔☎2.78™(roidz)]

뭐 그러면 걍 AES 사용하면 ?

[웹땔감dz(223.33)]

AES도 복조는 수신단에서 해 줘야하지 않나요 ㅠ 수신단은 저희 서버가 아니라 저희가 아무 것도 할 수가 없네여 ㅜ

[아둔☎2.78™(roidz)]

어헝~ 수신단에서 아무것도 할 수 없다면 그냥 SSL이나 TLS 만 믿을 수 밖에 없겠네얌.

[아둔☎2.78™(roidz)]

슈퍼해커 루비를 소환해 보아얌~

[웹땔감dz(223.33)]

자바가 JVM위에서 돌아갈테니 후킹도 좀 다를 거 같긴한데 그래도 불안하네얌

[웹땔감dz(223.33)]

일단 JAR는 사인해서 배포하긴하는데

[아둔☎2.78™(roidz)]

ㄴ 그 부분까지 고려한다면 답이 없어얌~ 애초에 자바가 디컴파일 하기도 쉽고.. 아무리 proguard 같은 걸로 난독화한 class 사용하고 별짓 다한다고 해도.. 졸라 엄청난 해커가 vm thread 덤프 뜰라고 덤벼들면 어쩔 수 없어얌. 보안은 결국 비용 싸움이에얌~ 뚫는 비용과 막는 비용의 적정 지점을 찾아야 해얌.

[아둔☎2.78™(roidz)]

어느 수준의 보안 등급이 필요한가에 따라서 자바를 버려야 할지도 몰라얌 ㅠㅠ

[아둔☎2.78™(roidz)]

그기에 대한 가이드라인 부터 잡아둬야 될 것 같아얌. 오해를 방지하기 위한 설명 및 설득 같은것. ㅇ

[웹땔감dz(223.33)]

저도 자바 버리고 싶네얌

[아둔☎2.78™(roidz)]

어느 정도는 되고, 어느 정도는 불가능하다라는 가이드라인 ㅇㅇ

[웹땔감dz(223.33)]

대체 왜 이걸 자바로 하라는 건가...