кодированая строка XXX сертификат = некодированая строка

[ArtGrek]

Здравствуйте!
Какие действия нужно провести, что бы получить строку из кодированой строки, если есть сертификат?
Спасибо!

[ArtGrek]

прочел около 10 статей связанных с моим вопросом, эту наизусть заучил)

http://pyatilistnik.org/ssl-chto-eto...-sertifikatom/

но не могу я понять
вот я в хроме играю Flash онлайн игру(клиент) и смотрю WireSharkом что происходит
клиент отправляет с 5000 порта на сервер на 443 порт ClientHello и когда рукопожатие прошло удачно,
начинается обмен TCP сообщений с 5000(клиент) порта на 9000(сервер) порт
вот сокращенный диалог рукопожатия

Handshake Protocol: Client Hello: 
	Random Bytes: 	0xb4, 0x21, 0x41, 0x74, 0x73, 0x27, 0x9b, 0xe7, 0xdb, 0x22, 0xc6, 0x03, 0x84, 0x6a, 
                        0xc8, 0x11, 0x9c, 0x10, 0x3d, 0xc6, 0x4c, 0x8c, 0x3b, 0xcd, 0xf6, 0xca, 0x17, 0xb7
	Session ID: 0
	Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
        Compression Method: null (0)
        Signature Hash Algorithm: 0x0601
        	Signature Hash Algorithm Hash: SHA512 (6)
         	Signature Hash Algorithm Signature: RSA (1)
	
Handshake Protocol: Server Hello:
	Random Bytes:
	Session ID: 0
	Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
	Compression Method: null (0)

Handshake Protocol: Certificate:
	Certificates:

Handshake Protocol: Server Key Exchange:
	EC Diffie-Hellman Client Params:
		Pubkey:
        Signature Hash Algorithm: 0x0601
        	Signature Hash Algorithm Hash: SHA512 (6)
         	Signature Hash Algorithm Signature: RSA (1)	
					
Handshake Protocol: Client Key Exchange:
	EC Diffie-Hellman Client Params:
		Pubkey:

Handshake Protocol: New Session Ticket:
	Session Ticket

Application Data Protocol: http-over-tls
	Encrypted Application Data:

создал переменную среду, что б ключи логировались в файл, а потом WireSharком получил rsakey.keys

RSA Session-ID:1864bd9ba339c4e92c88451ceb831959 28e3bfe2d1ef6aeac0b40162ffd87dea
Master-Key:d5de4344b190e0b723ef21f80cd82f7 353309772d1e214bfa84615b80523ea1b19 12eb049a24a811e411d50d10985fd6
CLIENT_RANDOM cea6cc7ac9d85d3378eff7facff419ef228 f33051945811f69f0aa02b72ae8ba
3881472badbc3379c01b598fdb26acffde8 6223189ab0bf1aeedd963c6dbb56a816a4d 15d7c2eb6e7a1aa92fbde1171c
...
последние 2 строки повторяются

добавил в WireShark и должен был увидеть трафик,
как описывалось во многих сайтах, но у меня кое что меняется, но не расшифровывается
клиент ведь может расшифровать, значит все необходимое у меня на компе есть
я не все нашел?

[p51x]

1. очередная тема об одном и том же... чем прошлые не устроили?
2. здесь взлом не обсуждается
3. с чего вы решили, что игровой протокол внутри ssl/tls текстовой/человекочитаемый/нешифрованный/несжатый?

[ArtGrek]

ну почему сразу взлом, я же не перехватываю чужой трафик, я парсю свой,
код клиента тоже есть, но он на ActionScript,
я в нем несколько месяцев разбираться буду(я все равно разбираюсь и в нем, параллельно)
и вопрос в том, как декодировать строку, с помощью тех данных, что мне на комп приходят, в принципе,
на примере того что я дал, потому что после того как я задал вопрос, меня попросили больше данных,
я же не у кого ничего не беру, разве это взлом?

3. с чего вы решили, что игровой протокол внутри ssl/tls текстовой/человекочитаемый/нешифрованный/несжатый?

декодированая строка, что приходит, в формате

{"sessionKey":"00000000000","msg":" success","messageId":"0000000000000 000000000000000000000","Name":"app. Response","command":"ping","eventTi mestamp":0000000000000}

у меня есть таки строки, можно в настройке отменять шифрование
если шифруется то методами что выбраны в рукопожатии как и сжимаются, я так понял из прочтенного
если после всех процедур, строка еще не полностью отобразится,
я смотрю в кодах клиента, я там тоже найду, что мне надо, вопрос времени...

1. очередная тема об одном и том же... чем прошлые не устроили?

не понял о каких темах? если о моих, я не получил декодированую строку
а в темах рассматривал различные способы

[ArtGrek]

2. здесь взлом не обсуждается

после изучения кучи нужной и не нужной инфы, понял

клиент отправляет с 5000 порта на сервер на 443 порт ClientHello

по 443 порту идут Get запросы, на подгрузку ресов(скрипты, картинки и прочее),
это всё, я могу увидеть в хроме или извлечь из кеша,
так что в расшифровке того, что у меня, всегда приходит и так в расшифрованном виде,
нет ничего криминального

обмен TCP сообщений с 5000(клиент) порта на 9000(сервер) порт

здесь идут команды для клиента которые, создатель захотел скрыть,
расшифровываются они самим клиентом, в коде клиента,
тут как раз дебагером можно проследить, что за чем
вот это, согласен, взлом. НО

я не понимал как и что спросить, меня как раз первое интересует.
вот решу я ClientSocketом принять Https Get ответ, у него ведь нет поддержки SSL как у IdHttp.
Да и вообще просто хочу понимать
одна из прочтенных статей: https://habrahabr.ru/post/258285/

по алгоритму RSA: клиент генерирует симметричный ключ,
подписывает его с помощью открытого ключа сервера и отправляет его на сервер.
В свою очередь, на сервере ключ клиента расшифровывается с помощью закрытого ключа.

подписывает его с помощью открытого ключа сервера

когда был получен этот открытый ключь, если это первое сообщение(ClientHello)

на сервере ключ клиента расшифровывается

как можно расшифровать то, что как я понял не шифровалось, ну допустим

расшифровывается с помощью закрытого ключа

каким бы он не был, как можно расшифровать случайное число зашифрованное неизвестным алгоритмом
a+b=с а потом c-z=a???
а даже если известным алгоритмом
с-b=a причем тут z(закрытый ключ)

[p51x]

когда был получен этот открытый ключь, если это первое сообщение(ClientHello)

Выже даже свои ссылки не читаете...

TLS Handshake
1. Так как TLS работает над TCP, для начала между клиентом и сервером устанавливается TCP-соединение.
2. После установки TCP, клиент посылает на сервер спецификацию в виде обычного текста (а именно версию протокола, которую он хочет использовать, поддерживаемые методы шифрования, etc).
3. Сервер утверждает версию используемого протокола, выбирает способ шифрования из предоставленного списка, прикрепляет свой сертификат и отправляет ответ клиенту (при желании сервер может так же запросить клиентский сертификат).
4. Версия протокола и способ шифрования на данном моменте считаются утверждёнными, клиент проверяет присланный сертификат и инициирует либо RSA, либо обмен ключами по Диффи-Хеллману, в зависимости от установленных параметров.
5. Сервер обрабатывает присланное клиентом сообщение, сверяет MAC, и отправляет клиенту заключительное (‘Finished’) сообщение в зашифрованном виде.
Клиент расшифровывает полученное сообщение, сверяет MAC, и если всё хорошо, то соединение считается установленным и начинается обмен данными приложений.

Вот rfc про ClientHello https://tools.ietf.org/html/rfc5246#page-38 , где там подписан ключом?

[ArtGrek]

Вот полный диалог из сниффера:

No. Time        Source          Destination     Protocol  Length  Info
1   0.001422	192.168.0.100	213.27.32.135	TCP       66      52169 → https(443) [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
2   0.139832	213.27.32.135	192.168.0.100	TCP       66      https(443) → 52169 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1440 SACK_PERM=1 WS=128
3   0.139871    192.168.0.100	213.27.32.135	TCP       54      52169 → https(443) [ACK] Seq=1 Ack=1 Win=66240 Len=0
4   0.141849    192.168.0.100	213.27.32.135	TLSv1.2   571     Client Hello
5   0.285696    213.27.32.135	192.168.0.100	TLSv1.2   1494    Server Hello
6   0.285847    213.27.32.135	192.168.0.100	TLSv1.2   1494    Certificate[TCP segment of a reassembled PDU]
7   0.285941    213.27.32.135	192.168.0.100	TLSv1.2   223     Server Key ExchangeServer Hello Done
8   0.290178    192.168.0.100	213.27.32.135	TLSv1.2   180     Client Key Exchange, Change Cipher Spec, Hello Request, Hello Request
9   0.428975    213.27.32.135	192.168.0.100	TLSv1.2   328     New Session Ticket, Change Cipher Spec, Encrypted Handshake Message
10  0.445552    192.168.0.100	213.27.32.135	TLSv1.2   556     Application Data
...

кто может описать происходящее, в этих сообщениях?
что посылается в первых трех?
если можно формулами, я походу текст не воспринимаю(
нпример:
в первом сообщении ClientRandomByte + д или ClientRandomByte зашифровано по д алгоритму
во втором сообщении ServerRandomByte / т или ServerRandomByte сжато т методом
Буду очень признателен, если кто то, чем то поможет.

[ArtGrek]

Я это читал, но то что вы показали происходит во второй строке(СерверХелло)
а это в в первой.
откуда клиент знает открытый ключ сервера когда он в первый раз в жизни к нему обращается

[ArtGrek]

можно еще месяц почитать и наверно разберусь, надеюсь раньше
но как мне понять по прочтенным статьям, когда везде есть отличаи
из вашей rfc

HelloRequest;
ClientHello;
ServerHello;
Certificate;
ServerKeyExchange;
CertificateRequest;
ServerHelloDone;
CertificateVerify;
ClientKeyExchange;
Finished;

у меня из снифира, он же не может неправеьно показать?

Client Hello
Server Hello
Certificate
Server Key Exchange
Server Hello Done
Client Key Exchange,
Change Cipher Spec,
Hello Request,
Hello Request
New Session Ticket,
Change Cipher Spec,
Encrypted Handsha

[Pavia]

Вот полный граф посылки на 35-36 странице.
https://tools.ietf.org/html/rfc5246#page-36
Смотрите там где * не все поля обязательные или их посылка зависит от ситуации.