Но даже если удавалось найти коллегу, с ним негде было сесть и поговорить. Переговорок не хватало, они постоянно были заняты, а вне переговорок мест не было вовсе. Так что многие общались прямо в open space, что было неудобно и им, и работающим вокруг.
Так в чем тогда плюс open space, помимо того, что он круто выглядит на фотках? Часто приходится слышать аргументы про деловую атмосферу и обмен идеями, а на деле даже поговорить с коллегами нормально не получается.
Так я и таким образом и проверял — набросал скрипт, который перебирает все шифронаборы, поддерживаемые локальным OpenSSL, и пробует подключиться к api.icq.net. Подозреваю, что ssllabs проверяет так же.
Как минимум эти поддерживаются:
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_SEED_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
Upd Нашел ваш комментарий ниже. Все еще хуже оказалось — нашелся еще и TLS_RSA_WITH_3DES_EDE_CBC_SHA, которого в моей версии openssl не было.
А какую задачу решают эти стендапы? Не подумайте, что пытаюсь троллить, действительно интересно. Работал пару лет в компании, где практиковались ежедневные собрания на 15-20 минут, каждый рассказывал, что делал вчера и что собирается делать сегодня. Но вот какой-то реальной пользы от этого так и не заметил — за отведенные 1-3 минуты просто невозможно нормально вникнуть в задачу, а информацию о том, что сотрудник Вася вчера работал над тикетом N и планирует продолжать над ним работать сегодня, обычно все мимо ушей пропускали. И я, каюсь, тоже. Возможно, конечно, что мы что-то делали неправильно… В своей команде я подобную практику отменил — считаю, что 1 собрания раз в неделю вполне достаточно.
При хорошей композиции таких методов и не должно появляться.
В идеальном мире — да. В реальном у такой реализации могут быть объективные причины: например, оптимизация производительности (если заранее было известно, что метод не будет использоваться в многопоточном окружении), ограничения сторонней библиотеки, легаси кода или даже железа.
А на вопрос «почему так» ответом может быть многотомный талмуд.
Талмудов никто и не требует. Достаточно пары фраз.
P.S. Как-то странно у вас получается — с одной стороны разработчик должен уметь писать идеальный код, а с другой стороны написать пару строк комментариев и поддерживать их в актуальном состоянии — это уже за гранью его возможностей.
Как по мне, так подобные четырехэтажные названия еще больше засоряют код, чем комментарии, и при этом хуже объясняют происходящее. В данном случае как минимум необходим комментарий, объясняющий, по каким причинам этот метод был реализован в таком виде.
Разработка ПО — это не только ради удовольствия и крутых техник. Это про деньги и прибыль. Поддержка комментариев и документации — это затраты.
Так комментарии и документация — это тоже про деньги и прибыль. Они призваны снизить стоимость внесения изменений в код. Представьте, к примеру, сколько времени затратит новый сотрудник на ознакомление с кодовой базой из тысячи модулей и сотен тысяч строк кода без единого комментария.
А разницы в вычислительном плане особо нет. Ведь сам по себе DH защищает только от прослушивания, активный же атакующий может вмешаться в обмен и подменить вам ключи. Поэтому DH-хэндшейк подписыватся сервером с помощью своего ключа, а для создания подписи он вычисляет все то же m^d mod n.
Не думаю, что они прямо на лету генерят сертификаты. Проще сгененерить в первый раз при обращении к сайту, а потом уже выдавать из кэша.
Не нужно расшифровывать RSA? Э-э-э… стесняюсь спросить, а сертификат — это по-вашему тогда что такое?) Открою страшный секрет: сертификат — это не что иное как открытый ключ RSA с некоторыми метаданными и цифровой подписью (ну или без нее) удостоверяющего. И в зависимости от выбранного шифронабора во время установления соединения он используется для обмена ключами — клиент шифрует пре-мастер ключ публичным ключом (сертификатом) и отправляет серверу, а сервер, соотвественно, расшифровывает это сообщение. Если же шифронабор использует протокол Диффи-Хеллмана, то история немного другая, но вычилительная сложность тоже приличная.
Далеко не факт, что тор просто так заработает — для коннекта к релеям тоже TLS используется и скорее всего тору не понравится, что кто-то ему подозрительный сертификат пытается подсунуть.
Единственное, что — RSA 1024 бита в MITM-сертификате это слабенько.
Ну это неспроста — все-таки расшифрование RSA вычислительно довольно-таки дорогая операция и если они действительно планируют перехватывать весь траффик, то их оборудованию может резко поплохеть.
Сейчас — да. Но что будет в будущем сказать сложно. Достаточно вспомнить пример Yahoo!, рыночная капитализация которой на пике пузыря доткомов году превышала 120 млрд долларов, а в итоге компания была выкуплена за 4.5 млрд.
Хм. В 2000 году?
Так в чем тогда плюс open space, помимо того, что он круто выглядит на фотках? Часто приходится слышать аргументы про деловую атмосферу и обмен идеями, а на деле даже поговорить с коллегами нормально не получается.
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_SEED_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
Upd Нашел ваш комментарий ниже. Все еще хуже оказалось — нашелся еще и TLS_RSA_WITH_3DES_EDE_CBC_SHA, которого в моей версии openssl не было.
Не уверен, что язык с динамической типизацией и gc — это лучший выбор для изучения основ программирования.
И давно он закрытым стал?)
В идеальном мире — да. В реальном у такой реализации могут быть объективные причины: например, оптимизация производительности (если заранее было известно, что метод не будет использоваться в многопоточном окружении), ограничения сторонней библиотеки, легаси кода или даже железа.
Талмудов никто и не требует. Достаточно пары фраз.
P.S. Как-то странно у вас получается — с одной стороны разработчик должен уметь писать идеальный код, а с другой стороны написать пару строк комментариев и поддерживать их в актуальном состоянии — это уже за гранью его возможностей.
Так комментарии и документация — это тоже про деньги и прибыль. Они призваны снизить стоимость внесения изменений в код. Представьте, к примеру, сколько времени затратит новый сотрудник на ознакомление с кодовой базой из тысячи модулей и сотен тысяч строк кода без единого комментария.
А разницы в вычислительном плане особо нет. Ведь сам по себе DH защищает только от прослушивания, активный же атакующий может вмешаться в обмен и подменить вам ключи. Поэтому DH-хэндшейк подписыватся сервером с помощью своего ключа, а для создания подписи он вычисляет все то же m^d mod n.
Не думаю, что они прямо на лету генерят сертификаты. Проще сгененерить в первый раз при обращении к сайту, а потом уже выдавать из кэша.
Ну это неспроста — все-таки расшифрование RSA вычислительно довольно-таки дорогая операция и если они действительно планируют перехватывать весь траффик, то их оборудованию может резко поплохеть.
Так и должно быть, это же самоподписанный сертификат.