UTMとはファイアウォールはセキュリティのためのアプライアンス NW 機器ですが、できることはレイヤー 4 までの制御、つまり、送信元、宛先の IP アドレスや TCP/UDP のポート番号により、通信を制御することまでです。 しかし、昨今ではマルウェア対策を始め、様々なセキュリティ対応が求められるようになってきており、 そのセキュリティ対策 1 つ 1 つに設備投資するのは効率的ではありません。 そこで登場したのが UTM (Unified Threat Management) です。 UTM は従来のファイアウォール機能に加え、アンチウィルスや IPS、スパム、URL フィルタ等の様々なセキュリティ機能が搭載しており、ライセンスを追加することで必要な機能を必要なタイミングで適用することができるセキュリティ製品です。 UTM の役割、機能UTM の機能には、主に以下の4つがあります。 ア
One of the popular ways to inspect HTTPS requests in iOS Apps is the Man-in-the-middle (MITM) attack. This technique requires a machine to be used as a proxy server for the client. For this to work, the client has to install the proxy server’s certificate into the device global trust store. By doing this, the client whitelists the certificate and hence allows HTTPS communication with the proxy ser
SSLのクライアント証明書を使って接続相手の認証まで行いたいケースで、 クライアント証明書が self signed certificate だと危ないのでは？という疑問を呟いたら @satoh_fumiyasu さんに突っ込んでもらえて、私の誤解を正してもらえました。…誤解したままだったら…と考えると、肝が冷えます。さとうさん、有難うございました。 .oO(…SSLのクライアント証明書って、オレオレにしちゃったら、認証として全く意味が無くなると思うのだけど、違うのかしら？…)— hkoba (@hkoba) 2017年10月4日 違いますね。— ふみやす＠シェルまおう(自称でない)🚲 (@satoh_fumiyasu) 2017年10月5日 むむむ？どんな使い方だと、オレオレなクライアント証明書でも安全になるのでしょう？ サーバーへのログインユーザ名にクライアント証明書の CN を使う
前回記事「RSA公開鍵から素数の積を取り出す方法」でも紹介しましたが、RSA鍵の生成には巨大な2つの素数p,qが必要です。近年一般的に使われている2048bit RSA鍵の場合、p,qの大きさは1024bit、10進で約308桁の数になります。 このRSAのアルゴリズム中ではpとqを法としたフェルマーの小定理（正確にはその拡張であるオイラーの定理）を利用しています。つまり、pとqが合成数だとRSA暗号の大前提が狂ってしまいますので、pとqには確実に素数を選ぶ必要があります。 ところで、OpenSSLのRSA鍵生成の実装では、pとqの素数判定にMiller-Rabin素数判定法が用いられています。Miller-Rabin素数判定法は片側誤りの確率的アルゴリズムで、「たぶん素数」「確実に合成数」の判定ができるようなものです。pとqの素数性が重要なのに、その判定に確率的アルゴリズムを使っても問題
443ポート以外が絶滅しそうです あちこちでポートは閉じられています。ssh や sftp もプロキシ利用も、各種ポートでは、全く外部に出れず、接続できないネットワークが多いです。 TCP/IPなのにIPとポートを使った通信ができない、壊れたネットワークが当然になりました。 これらの接続制限にとても不便を感じることが多いです。 サーバー管理者の気分一つでポートが空いたり閉じたり、私が触ってたネットワークではポリシーが統一されず、クソネットワーク管理者に振り回されて、動くはずのものが動かず、不便なことが多かったのです。そこで仕方なく４４３を使っています。 私達が利用する端末では80/443 のポートの外部接続が閉じられることは少なく、443であれば通信できます。 そのため、443ポートに様々なアプリケーションを起動していると思います。 443 ポートとIPアドレスが枯渇する・・・ よほどのG
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 今年はGoogle I/Oに初めて社員ではない立場で参加しました。全体の感想は Google I/O 2016まとめ（Web的視点） で公開していますが、今回はその中で、気に入ったセッションの1つである"Mythbusting HTTPS: Squashing security’s urban legends"について書いてみたいと思います。 セッションは大変良くまとまっていますので、YouTubeにあがっている動画を見れる人は動画を見て貰えれば良いのですが、時間が無いという人のために、その内容をまとめました。基本的には文字起こしに近い
問 1：以下のコンパイラを証明せよ（予告編） #kernelvm / Kernel VM Study Kansai 11th
Find all services using libssl to restart after an OpenSSL update Published: 14-07-2015 | Author: Remy van Elst | Text only version of this article ❗ This post is over nine years old. It may no longer be up to date. Opinions may have changed. When you update OpenSSL, the software that currently has the ssl libraries loaded in memory do not automatically load the updated libraries. A full system re
最近はSSL/TLSのセキュリティ問題が多発しているため、自分で運用しているサーバのSSL/TLSの設定をテストしたいという人は多いと思います。 SSL/TLSの状態をチェックするには、Qualys SSL LabsのSSL Server Testがよく使われます。しかしこれは外部から第三者にスキャンさせるわけですから、(心理的・社内政治的な)敷居が高いという点もありますし、そもそもインターネット側から直接接続できない環境のテストが行えません。 そこで、IPアドレスを指定するだけでよろしく対象のSSL/TLSサーバの状態をチェックしてくれるツールがあると便利だな、ということになります。本稿では、このような目的に利用されるsslscanというコマンドを紹介します。 sslscanはLinuxで動作し、ペネトレーションテスト用に使われるKali Linuxにもインストールされているお手軽なSS
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 「細かいと言うより長いよね」 はじめに こんにちは。ATS の脆弱性を発見した小柴さんや ATS に HTTP/2 の実装を行っている大久保さんと同じチームの一年目、匿名社員M さんからいじられている新人です。今回ありがたい事に、こういったすごい方々を含めモヒカン諸先輩方より「何か書かないの？」「いつ書くの？」という数々のプレッシャーお言葉をいただきました。 というわけで、SSL/TLS の Session 再開機能に関して書いていこうかと思います。 SSL/TLS は機密性、完全性そして真正性に対して安全な通信を行うための仕組みです。しかし、この仕組みは暗号技術を多用し特に接続において複雑なプロトコルを用い、Client, Se
先日ツチノコブログでクロスルート証明書の確認にIE6を使ってる話が紹介されてた。 確かに実機で確認するのは大事なのだが、SSL証明書が正しくインストールされているかチェックしてくれるサービスがいくつかある。 それで確認すればいいんじゃね？と思って調べてみたが、実はクロスルート証明書まで調べてくれるサービスは少ない。また各社チェックしてくれる内容が結構違う。 そこでオススメのSSL証明書チェックサイトを3つ厳選してみた。 Qualys SSL Labs SSL Server Test クロスルートを含む複数のチェインを表示してくれるのは試した限りここだけだった。 また、クロスルート以外にも脆弱なプロトコルや暗号アルゴリズムを使用していないか、BEAST、CRIME、Lucky13、BREACHなどの攻撃に対して対策されているかなども調べてくれる。 グレード表記や項目別スコア表示もあり。最低限
The information presented herein is without any guarantees and I’ll take no responsibility if any harm happens to you or your users. If you find any factual problems, please reach out to me([twitter:@hirose31]) immediately and I will fix it ASAP. http { server { listen 80; listen 443 ssl; server_name example.com; # BEAST: dont's use CBC ssl_protocols SSLv3 TLSv1; ssl_ciphers ECDHE-RSA-AES256-GCM-S
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
